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Kapitel 1 

Ziele und Grundidee 



Die neue Betriebssystem-Architektur soli eine vollstandige 
Verschmelzung von Datenbanken und Betriebssystemen er- 
moglichen, sowie den Funktionsumfang von verteilten Be- 
triebssystemen, Netzwerk-Betriebssystemen und Echtzeit- 
Betriebssystemen, mit oder ohne MMU-Hardware, auf ei- 
ner gemeinamen Code-Basis ermSglichen. 

Der Schlussel dazu ist eine universelle Erweiterbarkeit 
und dynamische Konfiguration zur Laufzeit, wodurch sich 
^flfe^ neue Architektur prinzipiell fiir jedes dieser Anwen- 
■ fcjwgsgebiete eignet. Daruber hinaus sollen neue Anwen- 
^^Pongsgebiete durch Konfigurationen erschlossen werden, 
die weder mit bisherigen Betriebssystemen noch mit Da- 
tenbanken auf einfache Weise realisierbar waren. 

Erreicht wird dieses Ziel durch die Abstraktionen Nest 
und Baustein. Es wird gezeigt, dass sich ein performantes 
Betriebssystem im Wesentlichen allein aus diesen beiden 
Abstraktionen aufbauen laBt. 

Gegeniiber aktuellen Betriebssystem- und Kern- 
Architekturen wird die innere Komplexitat in vielen Fallen 
reduziert, da eine relativ kleine Menge von primitiven 
Grundoperationen sehr weite Bereiche der wesentlichen 
Grundfunktionen eines Betriebssystems abdeckt; nicht 
nur Konzepte wie Inodes und deren Caches werden durch 
die Konzepte Nest und Baustein ersetzt, sondern sogar 
bisher als absolut notwendig erachtete Konzepte wie 
Dateisysteme als solche. 

CDie vorgestellte Architektur schreibt keine speziellen 
fclementierungs-Paradigmen vor; es sind sowohl Im- 
jhientierungen durch Server-Prozesse („Communicating 
quential Processes", z.B. in Mikrokern-Architekturen), 
als auch Implementierungen durch Rollenwechsel von 
Benutzer-Prozessen in Kern-Modi, als auch in Mischfor- 
men dieser Paradigmen moglich. 

1.1 Einfuhrung 

Die Grundidee dieser Arbeit besteht darin, ein Betriebssy- 
stem auf alien Ebenen und Schichten im wesentlichen aus 
zwei Abstraktionen aufzubauen: Nester und Bausteine. 

Prazisere Definitionen folgen spater; zum Verstandnis 
dieser Einfuhrung reicht es, sich eine Nest-Instanz als einen 
(virtuellen) Adressraum vorzustellen, in dem sich Daten be- 
finden konnen. Nicht alle Stellen dieses Adressraums mus- 
sen zugreifbar sein, es kSnnen beliebige Locher darin vor- 
handen sein. Dies ahnelt einem Sparse File unter Unix, nur 
mit dem Unterschied, dass ZugrifTe auf Locher als Feh- 




ler behandelt werden. In Erweiterung zu bisher verwen- 
deten Adressraum-Abstraktionen gibt es auf Nestern eine 
Verschiebe-Operation move, mit der ein ganzer Speicher- 
block im virtuellen Adressraum auf virtuelle Weise ver- 
schoben werden kann. Der Speicherblock erscheint an- 
schlieBend unter verschobenen virtuellen Adressen; die Im- 
plementierung erfolgt jedoch so, dass keine tatsachlichen 
Kopieroperationen im Speicher ablaufen, sondern nur der 
virtuelle Eindruck einer Verschiebung entsteht. 

Bausteine kann man sich als „Transformatoren" vorstel- 
len, die ein oder mehrere Eingangs-Nester in ein oder meh- 
rere andere Ausgangs-Nester transformieren. Bausteine las- 
sen sich instantiieretu d.h. man kann beliebig viele Inkarna- 
tionen des gleichen Baustein-TVps herstellen, deren Eingan- 
ge sich mit den Ausgangen anderer Baustein-Instanzen ver- 
binden oder „verdrahten" lassen. Als fur Menschen leicht 
verstandliche Darstellung benutze ich Zeichnungen, wie 
sie in der Elektro- und Digitaltechnik fiir Schaltbilder ver- 
wendet werden. Eine Baustein-Instanz wird als Kastchen 
mit linksseitigen Eingangen und rechtsseitigen Ausgangen 
gezeichnet. Die „Verdrahtungsregeln" sind gleich wie bei 
Schaltbildern in der Elektrotechnik. 

Als erstes Beispiel sehen wir uns in Abbildung 1.1 ein 
Szenario an, wie es bei konventionellen Betriebssystemen 
auftritt. Am Ende der Baustein-Hierarchie steht eine Instanz 
von rnmu_i386, die einen (nicht eingezeichneten) virtu- 
ellen Benutzer- Adressraum 1:1 auf ihr Eingangs-Nest ab- 
bildet, indem sie die MMU-Hardware (Memory Manage- 
ment Unit) benutzt. Der Benutzer-Adressraum enthalt ge- 
nau das, was sich im Eingangs-Nest dieses Bausteins „be- 
findet" bzw. was dort vom Vorganger-Baustein (virtuell) 
zur Verfugung gestellt wird. In Beispiel ist dies ein virtu* 
elles Prozessabbild, das von der union-Instanz generiert 
wird und als wesentliche Grundelemente jeweils ein Code-, 
ein Daten-, ein Stack-„Segment" sowie eine virtuelle Ab- 
bildung einer mmap-Datei zu einem ausfiihrbaren Prozes- 
sabbild zusammenstellt. Der Begriff „Segment" wird je- 
doch in dieser Arbeit nicht verwendet, da er mit der Nest- 
Abstraktion zusammenfallt bzw. einen Spezialfall davon 
darstellt (iiblicherweise enthalt ein Segment lediglich kei- 
ne Locher). 

Der union-Baustein wird aus mehreren Quellen ge- 
speist. Drei davon sind Nest-Instanzen, die man konven- 
tionell als „Dateien" oder „Files" bezeichnen wurde: eine 
Quelle ist eine device_ramdisk-Instanz, die fliichtigen 
Hauptspeicher bereitstellt (in der Praxis ist es sinnvoll, hier- 
fur eine gepufferte „temporare Datei" zu verwenden, damit 
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Abbildung 1.1: Erstes Beispiel 



j device„idT| — buEfer — | map_simple L - 



Idevlce.raiBdiskf 









code 




dir_sinple 




di r_s imple 


data 


union 












stack 


































• • 




r 




• • 









— | renjot 



dir_simple 



— • • • 

• • • 

• • • 



■ j mmu_i3S6 j 



Abbildung 1.2: Zweites Beispiel 



bei Speichermangel ein Auslagern auf Hintergrundspeicher 
moglich ist). 

Die „Datei"-Nester stammen wietjerum aus Quellen, die 
die Bezeichnung dir_* tragen. Die dir_*-Bausteine 
erfullen ungefahr die gleichen Funktionen wie Verzeich- 
nisse in konventionellen Dateisystemen. Im Unterschied 
zu konventionellen Dateisystemen implementieren sie kei- 
ne Verzeichnis-Zfczame, sondern nur fiache Verzeichnisse. 
Durch Schachtelung von dir_*-Instanzen lassen sich sehr 
leicht konventionelle Verzeichnisbaum-Hierarchien nach- 
bilden. Man kann sich eine dir_*-Instanz als eine Art 
^Container" vorstellen, der den Platz ftir seine Ausgangs- 
Nester in seinem Eingangs-Nest allokiert und verwaltet. 
Dabei wird die Tatsache ausgenutzt, dass das Eingangs- 
Nest die relativ billige Verschiebeoperation move bereit- 
stellt, mit deren Hilfe das Platzmanagement leicht Ids- 
bar wird. Verschiebe-Operationen konnen beispielsweise 
benutzt werden, wenn neue Ausgangs-Nester hinzukom- 
men oder wenn sich die GrdBe oder der Platzbedarf eines 
Ausgangs-Nestes andert 

Die billige virtuelle Verschiebeoperation muss irgendwo 
herkommen und implementiert werden; dies erledigt die 
map__simple-Instanz, die im Beispiel an der „Wurzel" 
der Verzeichnis-Hierarchie steht. Dort werden diejenigen 
Probleme gelost, die bei konventionellen Dateisystemen als 
Fragmentierungs-Probleme bekanntsind (Lokalitatsverhal- 
ten des Zugriffs). 

Die vorgeschaltete buf f er-Instanz sorgt fur die Ent- 
koppelung des zeitlichen Zugriffsverhaltens auf langsame 
Peripheriegerate wie z.B. Festplatten (device_ide), und 
laBt sich von der Funktionalitat her mit konventionellen 



Buffer-Caches vergleichen. 

Samtliche Leitungen in der Zeichnung reprasentieren 
Nest-Instanzen, die jeweils immer die gleiche Schnittstei- 
le besitzen. Die Bausteine sind daher in beinahe beliebiger 
Weise miteinander kombinierbar (die Frage ist nur, welche 
Kombinationen Sinn machen). 

Das Beispiel in Abbildung 1.2 soil die Flexibility die- 
ses Systems andeutungsweise demonstrieren. Im Vergleich 
zu vorhin kommen zwei remote-Instanzen hinzu, die das 
Client-Server-Paradigma auf Nester ubertragen. Eine re- 
mote-Instanz macht ein Nest so auf einem anderen Rech- 
ner verfiigbar, als ware es dort lokal vorhanden. Die ei- 
ne remote-Instanz sitzt im Beispiel am Ende der Hier- 
archie und macht ein komplettes Prozessabbild auf einem 
anderen Rechner verfiigbar. Dort befindet sich eine weite- 
re mmu_i3 86-Instanz, in der parallele Kontrollfliisse ab- 
laufen konnen, die sich physikalisch auf einem anderen 
Rechner befinden. Mit ahnlichen Konfigurationen laBt sich 
beispielsweise verteiltes Rechnen (number-crunching) oder 
Prozess-Migration betreiben. 

Die andere remote-Instanz stellt das andere Extrem von 
moglichen Einsatz-Szenarien dar: die bisherige „Wurzer 
der Verzeichnis-Hierarchie wird auf einem anderen Rech- 
ner verfiigbar gemacht; diese Funktionalitat entspricht etwa 
derjenigen von konventionellen Netzwerk-Dateisystemen. 
Wie man an diesem Beispiel sieht, braucht hierfur kein 
neuer Baustein-Typ implementiert zu werden. Die ande- 
ren Bausteine miissen dazu allerdings eine spater genau- 
er untersuchte Kompetenz, namlich die multiuser- oder 
mul tivers ion-Kompetenz. Nur wenn diese gegeben ist, 
diirfen Eingange mehrerer Baustein-Instanzen parallel am 
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Abbildung 1.3: Drittes Beispiel 



gleichen Ausgang angeschlossen werden. 

Das Beispiel 1.3 soil andeuten, wie sich die Funktiona- 
Datenbanken auf Basis der Abstraktionen Nest 
fc*M stein im P leme ntieren laBt Die Grundidee besteht 

WjyPelationale) Datenbank-Tabellen in Nestern abzule- 
gSHJer Baustein join fiihrt die bekannte Join-Operation 
durch, indem er an seinem Ausgang eine virtuelle Produkt- 
Tabelle zur Verfugung stellt, die lesbar und ggf. auch in 
gewissen Grenzen modifizierbar sein kann. Der nachfol- 
gende transaction-Baustein dient als Isolations-Puffer 
fur zwei transaktionale Sichten, die voneinander unabhan- 
gige isolierte Sichten mit der bekannten ACID-Eigenschaft 
(siehe z.B. [HR83, LS87, GR93]) bereitstellt. Die beiden 
Sichten werden im Beispiel in Benutzer-Adressraume ein- 
geblendet; damit haben wir einen Synergieeffekt zwischen 
dem Fachgebiet der Betriebssysteme und der Datenbanken 
ermoglicht. 

Wie man sich leicht vorstellen kann, sind transaktiona- 
le Sichten nicht nur fur die klassischen Einsatzgebiete in 
Datenbanken nutzlich, sondern konnen je nach Einsatz an 
verschiedenen Stellen einer Baustein-Hierarchie beispiels- 
5ur Isolation kompletter Prozessabbilder, oder im an- 
ktrem von Festplatten-Partitions-Abbildern dienen. 




Kapitel 2 

» 

Entwurfs-Prinzipien 



In diesem Kapitel mSchte ich die allgemeinen Prinzipi- 
en darstellen und begriinden, auf denen die vorgestellte 
Betriebssystem-Architektur beruht. 



2.1 



Generizitat: Wahl der angemes- 
senen Abstraktionsebene 

Ausgangbasis aller Uberlegungen ist die Funktionalitdt, 
die em Betriebssystem impiementieren muss, wenn es be- 
stimmte Anforderungen erfiillen soil. 

Die Anforderungen werden in dieser Arbeit als „freie Va- 
riable" betrachtet 1 . Anforderungen kdnnen sich fortlaufend 
andern; daher werden Klassen von Anforderungen auf in- 
formelle Weise betrachtet. 

Fur die zu implementierende FunktionalitSt gilt ein in- 
formelles Gesetz, das im Volksmund als "von nichts kommt 
nichts" bekannt ist. Alles, was das System leisten soil (un- 
abhangig davon, was das sein soli), muss irgendwo irgend- 
wie von irgendwem implementiert werden. 

Giingige Methoden zur L6sung dieser Problematik wer- 
den vor aliem im Software-Engineering, speziell bei den 
objektorientierten Entwurfs-Methoden (z.B. [Mey88]) ge- 
lehrt (Stichwort Anpassbarkeit an neue Aufgabenstellun- 
gen). Der objektorientierte Ansatz versucht dabei die Wie- 
derverwendbarkeit von Software-Modulen zu verbessern, 
indem er die Erweiterung bestehender Module und Schnitt- 
stellen zum Zwecke der Anpassung an neue Aufgabenstel- 
lungen ermoglicht. In der Praxis eingesetzte objektorien- 
tierte Software mit einer langeren Entwicklungsgeschich- 
te zeigt nicht selten eine riesige Ansammlung von Klassen 
mit einer ziemlich komplizierten Klassen-Hierarchie und 
schwer durchschaubaren Vererbungs- und Enthaltenseins- 
Beziehungen („is-a" und „has-a"-Beziehungen). Bei einge- 
hender Betrachtung findet sich darin viel Redundanz, die 
(vielleicht) hatte vermieden werden konnen, wenn man die 
jetzigen Anforderungen von Anfang an gekannt hatte und 
bei sorgfaJtigem Systementwurf beriicksichtigt hatte 2 . 

1 Der oft Ubliche Weg besteht in der Erfassung von Anforderungen vor 
dem Beginn jeglicher Entwurfs-Arbeiten. Wenn dies nicht moglich ist, 
konnte man der Versuchung erliegen, auf Anforderungen einfach nicht zu 
achten. Dies kann schweiwiegende Nachteile zur Fblge haben. Es geht 
mir daher n.cht daruro. eine Anforderungs-Anal yse abzuschaffen. sondem 
diesc in splliere Entwurfs-Phasen. insbesondere dden Detail-Entwurf kon- 
kreter Baustein-Typen, zu verschieben. 

^Dieser Eftekt ist nicht auf objektorientierte Systeme beschrankr er 
scheint mirein soziologisches und psychologisches Problem bei jeglicher 
Software-Entwicklung mit vielen Beteiligten zu sein. und dUrfte daher 



Die allgemeine Fragestellung lautet daher, wie man un- 
notige Redundanz in der Implementierung moglichst weit- 
gehend vermeiden kann, selbst wenn alle Anforderunoer 
(noch) gar nicht bekannt sind. 

2.1.1 Parametrische Generizitat 

Ein Mittel zur Vermeidung unnotiger Redundanzen ist der 
Einsatz von Generizitat. 

Als Generizitat betrachte ich jedes Mittel, das es er- 
laubt, ahnhche Dinge nur einmal hinzuschreiben, obwohl 
sie mehrmals vorkommen (evtl. in Varianten). 

Diese Definition ist wesentlich weit-reichender als die 
oftmals in der Literatur anzutreffende Verwendung des Be- 
gnffs Generizitat (siehe z. B. [Mey88, Kapitel 6 und 191) 
Ich verwende diesen Begriff nicht in der Reinform, sondern 
betrachte immer nur Spielarten 3 von Generizitat. 

Eine besondere Spielart ist die parametrische Generizi- 
tat. Beispiele hierfur sind Ersetzungmechanismen wie z.B 
der Lambda-Kalkiil (siehe z.B. [Fie88]) und seine Anwen- 
dung in funktionalen Sprachen wie Lisp oder ML oder 
Haskell (vgl. [Tho96]), Parameter-Substitution in Makro- 
Praprozessoren, Parameter von Template-Mechanismen in 
objektonenten Sprachen wie .C++, oder Anwendungen des 
Schlusselwortes generic in Ada. ParametrizitMt bedeu- 
tet, dass im Untersch'ied zu allgemeineren Ersetzungsme- 
chan.smen wie z.B. Chomsky-iy p -0-Grammatiken oder L- 
Systeme keine beliebigen Ersetzungen moglich sind, son- 
dern syntaktisch eindeutig gekennzeichnete Platzhalter, die 
formale Parameter genannt werden, durch Terme oder Aus- 
drflcke mit einer festgelegten Syntax {aktuelle Parameter) 
substituiert werden. 

In der Literatur wird haufig der nackte Begriff der Ge- 
nerizitat in ungefahr der gleichen Bedeutung wie hier die 
parametrische Generizitat verwendet, oder er steht in noch 

auch fur die hier vorgestellte Architektur ab einer gewissen GrBBenord- 
nung relevant werden (Conway's Law: ..systems mirror the structure of 
orgamzauons producing them"). Das objektorientierte Paradigma wird je- 
dodi manchmal so gelehrt. als ware die Erweiterung bestehender Schnitt- . 
stellen em Allheilmittel gegen die Problematik jeglicher Veranderungen 
von Anforderungen. Diese oft nur unterschwellig vorhandene Einstel- 
lung fdhit zusammen mit der durch die objektorientierten Sprachen stark 
erleichteiten Handhabung der Enveiterungsmechanismen sehr leicht zur 
Ausuferung von Klassenhierarchien (bzw. bei konventionellen Entwilrfen 
zum Anflanschen von "Balkonen") und clamit zur vermeidbawn Redupli- 
kation von implementierter Funktionalitat. 

3 0ber die in dieser Arbeit untersuchten Spielarten von Generziliu hin- 
aus kann es auch noch weitere geben. 
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weiterer Einschrankung synonym fur parametrische Poly- 
morphic von TVpen (vgl. [CW85]), beispielsweise bei Mey- 
er [Mey88, Kapite] 6 und 19] 4 . Das Konzept der para- 
metrischen Generizitat setzt nicht das Vorhandensein von 
Typpriifungen voraus 5 , jedoch sollten im Idealfall derar- 
tige Mechanismen vorhanden sein. Moderne funktionale 
Sprachen wie Haskell erlauben TVpsicherheit durch auto- 
matisierte Typ-Inferenz sogar bei Typ-Parametern (para- 
metrische Polymorphic von Typen, vgl. [CW85]). Makro- 
Praprozessoren fiihren dagegen meist nur eine reine Text- 
Substitution durch, die zwar universell fur beliebige pro- 
gram mi ersprachliche Konstrukte anwendbar ist, aber keine 
separate Pra-Compilierung und keine TVpprufung von Ma- 
kros ermoglicht 6 . 

Parametrische Generizitat erlaubt die Automatisie- 
rung immer wiederkehrender Programmierungs- und 
Formulierungs-Vorgange. Formale Parameter konnen mehr- 
mals auf verschiedene Weise durch verschiedene aktuelle 
Parameter substituiert werden. Dadurch ist eine kompakte 
Notation moglich, die Redundanz bei der Formulierung ei- 
ne^^oorithmus sparen hilft. Dieser Effekt ist nicht nur bei 
Mpjkrammierung i m Kleinen, sondern auch bei der Pro- 
■ Brung im GroBen nutzbar. 

^^Klgenden werde ich weitere Arten von Generizitat 
auf informelle Weise vorstellen, die sich durch parametri- 
sche Generizitat darstellen und simulieren lassen. Diese in- 
formell verwendeten Begriffe stellen kein eigenstandiges 
theoretisches Konzept dar, sondern sind vielmehr als Denk- 
Kategorien oder besser Denk-Hilfsmittel fur den Entwurf 
von komplexen Systemen durch Menschen gedacht. 

Die Grundregel beim Entwurf lautet: verwende Generi- 
zitat, wo immer es auf einfache Weise moglich ist und wo 

4 i 

Insbesondere im Vergleich zu den Mdglichkeiten der Textersetzung 
durch Makro-Prozessoren scheint Meyers Begriff von Generizitat deutlich 
enger gefasst zu sein als der hiesige Begriff der parametrischen Generizitat. 

Meyer meint in den Kapiteln 6 und 19, dass (parametrische) Gene- 
rizitat ohne Typprtifung sinnlos ware. Dem widerspricht jedoch u.a. die 
Lisp-Tradition seit den I960er Jahren, in der parametrische Generizitat 
ohne autnmatisierte Typprufungen benutzt wurde. Man muss lediglich die 
Typprttfungen notfalls „von Hand" zur Laufeeit machen, wenn man das 
Konzspt^der parametrischen Polymophie in solchen Sprachen wie der Ur- 
Lisp nutzen will. Vielleicht kommt dieses Missverstandnis auch 
I der nackte Begriff der Generizitat oftmals synonym fdr den 
^ eise eingeschrankten Begriff der parametrischen Polymorphie 
veTGHfflet wird. Diese eingeschrdnkte Verwendung verstellt den Blick Fur 
die wesentlich weiter reichenden Moglichkeiten von Generizitat im Sinne 
von Mechanismen zur Reduktion von Redundanz. 

6 Einige Beispiele sollen kurz verdeutlichen, dass Makro-Prozessoren 
trotz ihrer geringeren Sicherheit gegen versehentiiche Fehlbenutzung ei- 
nige nUtzliche Anwendungen von parametrischer Generizitat ausfuhren 
kdnnen, die mittels parametrischer Polymorphie nicht auf einfache Wei- 
se simulierbar sind: Beispielsweise kann man mittels Makro-Prozessoren 
die Felder von Strukturen (Records oder Klassen-Mitglieder) alphabetisch 
nach dem Namen oder nach kombinierten SchlUsseln wie (Typ t Name) sor- 
tieren. Man kann die Namen der Mitglieder einem bestimmten Namens- 
Schema unterziehen oder die Einhaltung eines bestimmten Namens- 
Schemas UberprUfen, beispielsweise indem die Namen aller Mitglieder ei- 
ner Klasse A die Form A_* haben mQssen. In statisch typisierten Spra- 
chen wie Eiffel oder C++ lassen sich statisch auswertbare Iteratoren iiber 
Klassen-Mitglieder definieren, die ansonsten nur in typlosen Sprachen wie 
Smalltalk auf einfache Weise generisch realisierbar sind.* Mittels genii- 
gend machtiger Makro-Sprachen wie beispielsweise TeX, die vom Typ 
Chomsky-0 sind, kann man theroretisch sogar automatische Typ-Inferenz 
zwischen Klassen betreiben und abstrakte Basisklassen aus einem gegebe- 
nen Klassenschema automatisch extrahieren. Derartige Techniken konnten 
beispielsweise zur Entdeckung bisher unentdeckt gebliebener Redundanz 
in groBen Soflware-Projekten dienen. 



immer es Redundanz einsparen kann 7 . 

2.1.2 Erweiterungs-Generizitat 

Die in der Objektorientierung verwendete Erweiterung 
bzw. Spezialisierung von Schnittstellen durch Vererbung 
(gelegentlich auch die Einschrankung von Schnittstel- 
len) lafit sich ebenfalls als eine besondere Art bzw. 
als Spezialfall von parametrischer Generizitat charakteri- 
sieren: Erweiterungs-Generizitat. Erweiterungs-Generizitat 
laBt sich auch durch theoretische Begriffe wie Untertypen 
(subtyping, vgl. [CW85]) oder praxisnahere Auspragungen 
wie Abstrakte Basisklassen beschreiben. 

Im Anhang A wird durch ein Beispiel nachgewiesen, 
dass sich die Vererbung prinzipiell durch parametrische Ge- 
nerizitat simulieren lafit 8 . Dieses Beispiel soli kein Vor- 
bild guten Software-Engineerings darstellen, sondern le- 
diglich zeigen, dass man prinzipiell die Vererbung sogar 
mit primitiven Mitteln wie dem C-Praprozessor nachbil- 
den kann, obwohl der C-Praprozessor nicht einmal beding- 
te Ausdriicke innerhalb von Makro-Expansionen auswerten 
kann (was jedoch zur Nachbildung uberschriebener Metho- 
den sehr nutzlich ware). Der interessierte Leser, der das 
Beispiel aus Anhang A nachzuvollziehen versucht, wird 
auf den Kunstgriff verwiesen, dass man in einigen Makro- 
Sprachen die Namen von zu expand ierenden Makros auch 
berechnen kann; im C-Praprozessor benotigt man dazu den 
Konkatenations-Operator ##. Dieser Kunstgriff wird u.a. 
auch gerne in Kreisen von TBX-Programmierern eingesetzt 
(vgl. \csname in [Knu94]). 

Aus theoretischer Sicht handelt es sich hierbei urn Funk- 
tionen hoherer Ordnungen. Einige Verfechter objektori- 
entierter Entwurfsmethoden wie z.B. [Mey88, Abschnitt 
3.6.3] benutzen im Vergleich zu hier einen eingeschrankten 
Begriff von Generizitat, dem sie dann nicht die Machtigkeit 
zutrauen, den er bei entsprechender Fassung in der Theorie 
jedoch besitzt. Diese Machtigkeit umfasst auch wesentliche 
Grundkonzepteder Objektorientierung. Daher betrachte ich 
Generizitat schlechthin als Oberbegriff, unter den die Ob- 
jektorientierung als Spezialfall untergeordnet wird. 

2.1.3 Kompositorische Generizitat 

Eine weitere besondere Form von Generizitat spielt bei 
uniformen IO-Schnittstellen wie [Che87], in stapelbaren 



7 ObermaBiger Einsalz von Generizitat kann auch die Redundanz erh6- 
hen, die Durchschaubarkeit von Software verschlechtern, die Performanz 
verschlechtern, und damit zu negativen Effekten fiihren. Eine objektiv ex- 
akte Einschatzung und Abwagung der Einsatzstellen scheint schwierig und 
ist daher oftmals der subjektiven Einschatzung des jeweiligen Entwerfers 
unterworfen. 

8 Dieses Beispiel widerspricht nicht der scheinbar genau umgekehrten 
Aussage von Meyers Analyse in [Mey88, Abschnitt 19.3]. Meyer verwen- 
det den Begriff der Generizitat synonym zu einer Auspragung von parame- 
trischer Polymorphie, wie sie speziell in Ada auftritt. Im Gegensatz dazu 
verstehe ich unter parametrischer Generizitat ein sehr viel allgemeineres 
Konzept, unter Generizitat schlechthin sogar eine nochmals allgemeinere 
Denk-Kategorie. Man muss sich diese unterschiedlichen Begriffsbildun- 
gen vor Augen halten, wenn man die Aussagen miteinander vergleicht. 
Das hier vorgestellte Beispiel stUtzt jedoch die hier vorgeschlagene Be- 
griffsbildung. 



2. /. GENERIZITAT: WAHL DER ANGEMESSENEN ABSTRAKTIONSEBEi 



Dateisystem-Layern wie [HP33p, in den Streams von Sy 
stem V Release 4 [GC94, Kapitel 7], oder beim Port- 
Konzept von Gnu Hurd [Hur] erne Rolle, die man als Vor- 
laufer der hier vorgestellten Architektur ansehen kann. Kon- 
zeptuell wird bei den genannten Systemen die gleiche Art 
von Generizitat wie bei der vorgestellten Architektur favo- 
risiert, die ich kompositorische Generizitat nennen mochte. 

Auf den ersten Blick scheint kompositorische Generi- 
zitat keine parametrische Generizitat zu sein, da die syn- 
taktische Darstellung oftmals anders als in funktionalen 
Sprachen oder Makro-Sprachen aussieht Wie wir jedoch 
in Abschnitt 6.3 sehen werden, implementieren Bausteine 
Funktionen in einem weiteren Sinn, wobei die Verdrahung 
von Bausteinen zu komplexeren Netzwerken sich als eine 
spezielle Art der Komposition von Funktionen auffassen 
Iasst. Kompositorische Generizitat ist ebenfalls eine Vari- 
ante von parametrischer Generizitat, die sich allerdings von 
der Erweiterungs-Generizitat in der Entwurfs-Philosophie 
(nicht notwendigerweise jedoch in den verwendeten Me- 
chanismen) stark unterscheidet: wahrend objektorientierte 
Paradigmen ebenso wie die in den 1970er Jahren popula- 
ren Hierarchie-Konzepte [Dij68, Dij71, BS75] ausdrticklich 
die Erweiterung von Schnittstellen bzw. von abstrakten Ma- 
schinen urn neue Funktionalitat durch Hinzunahme weiterer 
Operationen und Abstraktionen bezwecken und anstreben, 
wird bei kompositorischer Generizitat das Gegenteil ange- 
strebt: die Schnittstelle muss in den Grundzugen auf alien 
Oder moglichst vielen Hierarchieebenen gleich oder zumin- 
dest weitgehend kompatibel bleiben, damit eine vielfaltige 
Kombinierbarkeit moglich ist. Bei kompositorischer Gene- 
rizitat wird die Erweiterung der Funktionalitat nicht durch 
Erweiterung der Schnittstellen, sondern durch Hinzunahme 
weiterer Funktionalitat innerhalb der kombinierten Funk- 
tionen erzielt; neue Funktionalitat ergibt sich mithin durch 
die besondere Art der Verdrahtung zu einem Netzwerk. 

2.1.4 Universelle Generizitat 

Urn kompositorische Generizitat iiber das bisherige Anwen- 
dungsfeld von IO-Schnittstellen [Che87] hinaus auf das ge- 
samte Betriebssystem ausdehnen zu konnen, miissen nicht 
nur die Urbild- und Bildbereiche der beteiligten Funktionen 
zueinander passen, sondern diese mussen daruber hinaus ei- 
ne weitere Art von Generizitat ermoglichen, die ich univer- 
selle Generizitat^ nennen mochte. Beispiele fur universelle 
Konstrukte sind Hiringmaschinen oder Registermaschinen, 
die prinzipiell andere Turing- oder Registermaschinen si- 
mulieren konnen. Universelle Generizitat ist analog dazu 
die Fahigkeit, alternative Funktionalitaten, Reprasentatio- 
nen, Zugriffs vernal ten, Granularitaten etc. auf relativ ein- 

9 Die in [HP94] vorgestellte hierarchische Modularisierung von Datei- 
systemen verwendet einige der hier vorgestellten Konzepte, beschrankt 
sich jedoch nicht nur auf die Funktionalitat von Dateisystemen und ver- 
wendet deren aufwendigere Schnittstellen (insbesondere zum Manage- 
ment von Dateisystem-Unterbaumen). sondern basiert auch inharent auf 
konventionellen Daleisyslem-Konzepten und -Abstraktionen wie vnodes 
vnode-Operationen und vf s, die in der vorliegenden Arbeit keine Rolle 
spielen. 

u |Auch universelle Generizitat IiiQt sich durch parametrische Generizitat 
ausdrUcken. Die Unterscheidung der verschiedenen Arten von Generizitat 
ist daher letzlich nur ein menschlicher Verstehensansatz, der eine bestimm- 
te Denkwcise beim Entwurf kommimizierbar machen soil 



fache Weise simulieren zu konnen; der Begriff ist daher 
kein absoluter Begriff, sondern gilt immer nur relativ zum 
Universum der jeweils simulierbaren alternativen Konzep- 

Ein Beispiel fur universelle Generizitat in Betriebssyste- 
men ist die bekannteFile-IO-Schnittstelle von Unix [RT741 
die aufgrund ihrer Fahigkeit zu 10 mit beliebiger dyna- 
mischer Blocklange und beliebigen Zugriffsmustern auch 
altere Ftle-Konzepte wie z.B. Lochkartenstapel mit fester 
Satzlange simulieren kann, daruber hinaus aber auch unter- 
schiedhche Zugriffsmuster verschiedener Leser und Schrei- 
ber ermoghcht, die mit den vorher ublichen satzorientierten 
IO-Schnittstellen nicht auf einfache Weise realisierbar wa- 
ren. Dieses inzwischen zur Selbstverstandlichkeit geworde- 
ne histonsche Beispiel einer Vereinfachung durch univer- 
selle Generizitat zeigt auf, dass „weniger oft mehr" ist: der 
Verzicht auf das Konzept eines „Datensatzes" (record) in 
Unix macht nicht nur die Schnittstellen und die Implemen- 
tierung einfacher, sondern verbessert daruber hinaus sogar 
noch die Funktionalitat. Universelle Generizitat ist daher in 
hohem MaBe erstrebenswert und wird insbesondere beim 
Entwurf der Nest-Abstraktion (Kapitel 3) eine herausragen- 
de Rolle spielen. 



2.1.5 



Fragen der Anwendung von Generizi- 
tat 



Die zentralen Fragen bei der Anwendung von kompositori- 
scher und universeller Generizitat lauten: 

• Wie sollen die Bild- und Urbildbereiche aussehen? 

• Welche Funktionalitaten sollen durch die Bausteine 
realisiert werden? 

Diesen Fragen liegt das gefneinsame Problem der Wahl 
der am besten geeigneten Abstraktionsebene fur die zu 
losenden Aufgaben (bei teilweise unbekannten Anforde- 
rungen) zu Grunde. Die Vorstellung und Propagierung ei- 
nes bestimmten Mechanismus alleine nicht viel uber & de- 
ren konkrete Anwendung in einem bestimmten Gebiet aus. 
Entwurfs-Entscheidungen sind nicht immer eindeutig auf- 
grund gesicherter Methoden und Erkenntnisse losbar, da be- 
reits die Betrachtung der Problemsteliung ein menschlicher 
Interpretationsprozess ist. In dieser Arbeit werde ich daher 
der Pragmatik einen vergleichsweise groBen Raum emrau- 
men und syntaktische und semantische Konstrukte nur zur 
Verdeutlichung und Notation der zugrundeliegenden Ideen 
verwenden. 

Eine konkrete Wahl von Abstraktionsebenen konn- 
te die berechtigte Kritik auf sich Ziehen, daB prazise 
Aussagen iiber Vor- und Nachteile bestimmer Entwurfs- 
Entscheidung en nicht oder nicht ausreichend moglich sind. 

n Die Problematik bei einer formaleren Fassung des BegrifTes der uni- 
versellen Generizitat besteht darin, was man unter einfach verstehen soli. 
Ldsst man „kompIizierte" Simulationen zu, dann' kann man wesentliche 
Teile der Funktionalitat in der Abbildung auf das zu simulierende Konzept 
verstecken, anstatt es im benutzten Grundkonzept zu Idsen. Die ..Einfach- 
heit einer Simulation lasst sich auf mehrere verschiedene Weisen formal 
fassen; da es mir bei dieser Diskussion nur urn Denk-Kategorien wahrend 
der Entwurfs-Phase geht, habe ich auf formale Fassungen all dieser Be- 
gnffe verzichtet. 
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KAPITEL2 



Im Forschungsgebiet der Betriebssysteme hat es bisher mei- 
nes Wissens nach keine Evaluation verschiedener Entwurfs- 
Konzepte auf der Ebene ganzer Betriebssysteme gege- 
ben, die diese Konzepte als solche auf einer wirklich ver- 
gleichbaren Grundlage (d.h. deren isolierte Auswirkung auf 
gut messbare Grofien ,wie Performanz oder weniger «ut 
messbare GroBen wie die Anderungsfreundlichkeit) ohne 
Einfluss weiterer versteckter Parameter wie z.B. die Kennt- 
nisse und Fahigkeiten der jeweiligen Implementierer un- 
tersucht hatten 12 ; da solche Evaluationen nach aktuellem 
Stand kaum moglich erscheinen, ist es stattdessen iiblich 
das Fur und Wider verschiedener Entwurfs-Alternativen 
durch informelle Argumentation darzustellen. 

Der Begriff der .Architektur" wird in dieser Arbeit in ei- 
nem weiteren Sinn verwendet als vielerorts in der Litera- 
tur (vgl z.B. [PC75, Jon80, MP81, B+95, Lie95b, EK095 
Ass96]) \ da er weder feste Implementierungsparadigmen 
wie ..communicating sequential processes" (siehe [Hoa78]) 
vorschreibt' 4 , noch die Frage nach Kern-Gr6Ben und - 
Umfangen (vgl. [Lie95b]) in festiiegender Weise beantwor- 
teywch die Frage nach den Grenzen zwischen Benutzer- 
Mf»aumen und Kern- oder Server-Adressraumen fest- 
■fc^»ern diese Fragen je nach Systemkonfiguration an- 
d^Wsen kann, ohne den Quelltext des Systems andern 
zu miissen. Im Vergleich zur konventionellen Handhabung 
des Architektur-Begriffes kdnnte man die hier vorgestell- 
te Architektur daher auch als Meta-Architektur bezeichen; 
ich habe davon jedoch Abstand genommen, da der Begriff 
..Architektur" laut Brockhaus schlicht ..Baukunst" bedeutet 
und daher die in derLiteratur teilweise vorkommendeenge- 
re Auffassung nicht impliziert. In der Bedeutung als „Meta- 
Architektur" werden einige konventionelle Architekturfra- 
gen, die bisher als ..festverdrahtet" betrachtet'worden sind 
und deren Diskussion in der Literatur groBe Beachtung ge- 
funden hat, zu dynamischen Parametern, deren Variation 
einen direkten Vergleich dieser Paradigmen bei einer Eva- 
luation erleichtert ,s . 



'S-PRINZIPIEN 




-Ausnahmen hiervon gibt es nur bei Untersuchungen Uber konkrete 
A !2SS!r" Mechanismen bei speziellen wohldefinierten Teilproblemen 

7 anscheinend wenig beachteten Aitikel (Ant90J beschreibt An- 
Jpr in teilweise sehr schwer zu veistehendem und manchmal 
, w __F u "g zu mterpretierendem Englisch, eine .jegulare Architektur" 
dieW'anderer formeller Darstellung dem Kerngedanken der hier vor- 
gestellten Architektur sehr nahe kommt, dabei jedoch auf Erweiterungs- 
Genenzitat und weniger auf kombinatorische Generizitat ausgelegt ist 
Im Detail gibt es weitere gravierende Untercchiede, so etwa bei der 
enornien Anzahl von Schnittstellen-Funktionen, bei den Instantiierunas- 
Mechanismen, den fest eingebauten Schutzmechanismen. und mSglicher- 
weise auch bei der Anzahl der ..Ausgange" pro ..Buustein" (in alien Bei- 
spielen kommt immer nur ein einziger Ausgang vor. einen grammatisch 
klaren exphziten Hinweis auf mehrere ..Ausgange" konnte ich nicht fin- 
den). Weiterhin fehlt bei Antonov der hier vorgestellte Ersatz von Datei- 
systemen durch dynamische hierarchische Instantiierung von Bausteinen- 
eine Unterscheidung verschiedener Betriebsarten oder Betriebsmodelle ist 
ebenfalls nicht zu erkennen. 

' 4 Eine Ausnahme ist [Str78], wo Stroustrup die Unabhiingigkeit 
und Austauschbarkeit der Implementierungsparadigmen von den Modul- 
schmttstellen aufzeigt. und damit den Architekturbegriff ebenfalls weiter 
aufTasst. Leider scheint dieser grundlegende Aitikel wenig Beachtung in 
der Betriebssystem-Literatur gefunden zu haben, da auch Jnhrzehnte spn- 
terdie Verwendung fester Implementierungsparadigmen immer noch zum 
Stand der Techmk zu gehoren scheint. 

"Dies gilt nur fur Entwurfs-Entscheidungen. die innerlmlb der hier vor- 
gestellten Architektur offengelassen und daher parametrisierbar sind; auf 
der Ebene der Meta-Architektur selbst werden jedoch auch von mir feste 



Zur Begriffsbildung: statt mit Architektur oder Meta- 
Architektur konnte man die vorliegende Entwurfs- 
Methodik auch als Framework™ oder als Komponenten- 
Architektur" bezeichnen. Da diese Begriffe nach weit 
verbreiteter Auffassung zur Zeit sehr eng mit der Objek- 
tonentierung verknupft sind. die ich in der vorliegenden 
Arbeit zwar ermogliche, aber nicht zur zwingenden Vor- 
ausseteung der Architektur erhebe, habe ich von einer 
derartigen Begriffsbildung vorerst Abstand genommen. 
Im U nterschied zu szyperskis Komponenten-Begriff 
[Szy98] konnte man die hier vorgeschlagenen Bausteine 
auch als leichtgewichtige™ instantiierbare" Komponenten 
charakterisieren . 

Bei Konflikten zwischen verschiedenen Arten von Ge- 
nerizitat bei zu treffenden Entwurfs-Entscheidungen propa- 
giere ich zumindest fur die Anwendung in Betriebssyste- 
men die folgende Priorisierung miteinander konkurrieren- 
der Arten von GenerizitSt: 



Entscheidungen gefallt. die prinzipiell (wie auch bei bisherigen Architek- 
turen) der oben genannten Kritik unterliegen und im Einzelfall weiterer 
Evaluation und ggf. einer Revision bedurfen. 

Dieser Begriff wird in der Praxis meist mit der Objektorientierang ver- 
knupft (vgl. z.B. [JH02. S. 273]: ..Frameworks stellen komp!e£ S 

SSSTT!! '« : 6 T / nst u antiiemn « zu einer Applikation ohne Vereitung 
nicht denkbar ware"), bis hm zur Bezeichnung einer konkreten Implemen- 
ting emer Sammlung von abstrakten Basisklassen, und kbnnte daher 
zu Missverstandmssen fuhren. Eigentlich wiinte der Begriff Framework 
gut auf die hier vorgestellte Architektur passen. wenn er nicht bereits auf 
die zitierte Art e.ngeschrankt ware. Eventuell wiire es sinnvoll. Ober eine 
Erweiterung dieses Begriffs nachzudenken; dariibersollte jedoch ein we£ 
gehender Konsens erzielf werden. 

• " Zura l a ' ctuellen D 'Skure zwischen Broy /Sindersleben [BS02] und Jah- 
nichen / Herrman [JH02] tiber Wesen. Vor- und Nachteile der Objek^- 

unrnh r T, 8, -' nS . d T 2Um Zusam ^"ha»g ^Lschen Komponenten 
und Objektonentierung, kann die vorliegende Arbeit eine Erweiterung der 
Perspekuve beitragen. Man kdnnte die hier vorgestellte Architektur oh- 
ne weiteres ate Komponenten-Architektur bezeichnen, obwohl sie nicht 
unbedmgt auf der Objektonentierung aufbaut und damit von der vorherr- 
schenden Meinung in dieser Hinsicht abweicht. Wie in Abschnitt 6 2 ge- 
zeigt wird, wird objektorientierte Vererbung von der hier voreestellten Ar- 
chitektur ermiiglicht. aber nicht zur zwingenden Voraussewng erhoben 
Ich habe in den Beisp.elen des Kapitels 4 besonderen Wert darauf gelegt 
die Grandfunktionalitat eines Betriebssystems moglichst nur mit Hilfe 
kompositonscher Generizitat zu renlisieren und Erweiterungs-Generizitat 
praktisch vollsiandig zu vermeiden. Damit existiert ein Beispiel. daTSnl 

gTJZZT^. ^ ° hne/eWC Verknu P fu "g ™' einer wesentlichen 
Grand dee der Objektonentierung (egal ob man sie nun mit ..Vererbung" 
oder a s Spezialfall einer ..Delegation" bezeichnet) realisiert. Damit dUrf- 
te gentigend Substanz zur Erhattung der These vorgebracht worclen sein 
dass Komponenten-Architekturen als weitgehend orthogonal zur Anwen- 
dung spezifisch objektorientierter Entwurfs-Methoden betrachtet werden 
hmnen. Eine solche Betrachtung hiingt allerdings von der Definition von 
..Objektonentierung" ab; je nach Geschmack oder Herkunft aus einer be- 
stimmten Schule kann man die jeweiligen Begriffe so definieren. dass Ob- 
jektenentierung einen Oberbegriff darstellt, unter den auch Komponenten- 
Achitekturen als ergiinzende Anwendung des Prinzips der kompositori- 
schen Generizitat fallen, oder genau umgekehrt. oder dass zwei zueman- 
der orthogonale Begriffe entstehen. Ich pliidiere aus Grunden der metho- 
dischen Sparsamkeit far die dritte Variante. 

"Vgl. [Szy98. Abschnitt 4.1.8]. Das vermutete Phiinomen ..maximi- 
zmg reuse minimizes use" scheint mir auf der impliziten Annahme von 
Erweiterungs-Genentfit als Maximierangs-Strategie Uber Komponenten- 
Grenzen hinweg zu berahen; dieses Phiinomen wird durch das Konzeot 
der kompositorischen Generizitat und der univereellen Generizitat in sein 
Gegenteil verkehrt. 

"Szyperski [Szy98] betont mehrmals (Abschnitte 1.5. 4.1.1) dass die 
Iastantiierung von Komponenten wegen der Statuslosigkeit sinnlos wa- 
re. Im Unterschied dazu haben beispielsweise mehrfache lastanzen von 
aix l.* -Bausteinen durchaus Sinn, da es durchaus auf die Stetlww in ei- 
ner Baustein-Hierachie bzw. auf den Verdraluunga-Kimtexl ankomitiL 




2.3. DAS VERANTWORTUNGS-PRINZIP 

m 

1. Universelle Generizitat 

2. Kompositorische Generizitat 

3. Erweiterungs-Generizitat 

Eine genaue Evaluation der Vor- und Nachteile dieser Prio- 
risierung fur die Anwendung in Betriebssystemen steht 
noch aus, mindestens solange das hier vorstellte Konzept 
noch nicht in die Praxis umgesetzt worden ist. 

2.2 Trennung von Mechanismus / 
Strategie / Representation 

Im Betriebssystem-Bau ist das Prinzip der Trennung von 
Mechanismus (mechanism) und Strategie (policy) schon 
sehr Iange bekannt und benutzt worden; eine Darstel- 
lung dieses Prinzips und ihrer Vorteile findet man z.B. in 
[LCC+75, CJ75]. 

Als unabhangig von Mechanismen und Strategien ist fer- 
nerhin die Reprasentation zu betrachten 20 . Beispielswei- 
se lasst sich ein Monitor [Han73, Hoa74] als program- 
miersprachliche Reprasentation eines Mechanismus verste- 
hen, der prinzipiell wie ein binares Semaphor funktioniert; 
die programmiersprachliche Reprasentation eines Monitors 
lasst sich bekanntermassen auf einfache Weise mittels Se- 
maphoren und konventionellen Sprachmitteln simulieren 21 . 
Hieraus ist zu erkennen, dass die Auswahl einer einzigen 
Reprasentation ausreichend ist und Redundanz vermeiden 
hilft 22 ; diese Reprasentation sollte jedoch moglichst univer- 
sell und einfach handhabbar/ verstehbar sein. DieEntschei- 
dung fur die Auswahl einer bestimmten syntaktischen Re- 
prasentation ist daher der Pragmatik zuzurechnen; im Rah- 
men dieser Arbeit wird nicht weiter darauf eingegangen; 
insbesondere werden Reprasentationsfragen nicht zur Aus- 
wahl von Mechanismen oder Strategien herangezogen. 

Die Abgrenzung zwischen Mechanismus und Strate- 
gie ist nicht immer eindeutig moglich, da sie vom Kon- 
text und der gewahlten Abstraktionsebene abhangt. Eine 
Strategie kann beispielsweise ihrerseits wieder in Unter- 
Strategien und Unter-Mechanismen zerfallen. Auch Mecha- 
nismen konnen in ihrer Feinstruktur wiederum Strategien 
enthalten. 



2,) Eine ahnliche Auffassung vertritt Parnas in [Par78]. 

2I Hiervon unabhangig sind wiederum die Warte-Strategien mehrerer 
eintrittswilliger Prozesse wie beispielsweise die FIFO-Strategie (als inter- 
essantes Realisierungsbeispiel hierzu siehe [RK79]). 

22 In der Praxis ist dieser Vorsatz nicht immer konsistent durchzuhalten, 
vor allem in groBeren Projekten mil vielen Beteiligten, die unterschiedli- 
che Interessen verfolgen. So kdnnte es beispielsweise vorkommen, dass 
eine Interessengruppe die Programmiersprache Ada bevorzugt, die andere 
die Sprache C (Argumente flir die jeweiligen Positionen sind sattsam be- 
kannt: Ohne Zweifel ist Ada die sicherere, produktivere und wartungsar- 
mere Sprache, der GroBteil bereits existierender und ausgetesteter Softwa- 
re ist jedoch in C oder C++ geschrieben. zu der unbedingt Kompatibilitat 
zu wahren ist). Prinzipiell lasst sich die hier vorgestellte Architektur nicht 
nur einheitlich in einer der beiden Sprachen realisieren, sondern auch bau- 
steinweise in beliebigen Mischungen, sofern die Aufruf-Konventionen der 
jeweiligen Sprachen und Compiler zueinander kompatibel sind. Da dies 
nicht nur die Redundanz, sondern auch den Integrationsaufwand und mog- 
liche Fehlerquellen erhflhen kann, sollte dies moglichst vermieden, auf je- 
den Fall aber sehr gut Oberlegt und begriindet werden. 
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Auf relativ grober Abstraktionsebene korrespondieren 
Mechanismen und Strategien mit den hier propagierten Ab- 
straktionen Nest und Baustein auf ziemlich direkte Weise: 
ein Nest stellt einen Satz von abstrakten Mechanismen zur 
Verfugung, ein Baustein implementiert eine Strategie oder 
eine Menge von Strategien. 

Die Nest-Schnittstelie stellt insofern abstrakte Mechanis- 
men bereit, als dass die konkrete Implementierung der Me- 
chanismen durch spate Bindung (late binding), zu Stande 
kommen kann. 

Die Trennung zwischen Mechanismus und Strategie wird 
durch die hier vorgestellte Architektur nicht nur direkt un- 
terstiitzt, sondern geradezu zum Prinzip erhoben. Da Bau- 
steine wiederum andere Bausteine enthalten oder uber ih- 
re Eingange benutzen konnen, lasst sich das Prinzip der 
schrittweisen Verfeinerung auf die Trennung in Mechanis- 
men und Strategien anwenden: eine Baustein-Hierarchie 
fungiert gleichzeitig als hierarchisch-rekursive Zerlegung 
des zu losenden Problems in Mechanismen und Strategien. 

2.3 Das Verantwortungs-Prinzip 

Verantwortung und ihre Aufteilung ist ein Prinzip, das in 
komplexeren menschlichen Gesellschaften und Systemen 
wie Firmen oder Behorden seit Jahrtausenden mit Erfolg 
praktiziert wird; als Ergebnis eines Auf tei lungs vorgangs 
von Verantwortung entstehen Zustandigkeiten. Im Kontext 
von Betriebssystemen wurde Verantwortung ebenfalls als 
Strukturierungs-Leitlinie eingeseizt (ohne dass dies den je- 
weiligen Autoren vollig bewusst gewesen sein muss 23 ): die 
in den 1970er Jahren popularen hierarchischen Strukturen 
[Dij68, Dij71] lassen sich beispielsweise durch Aufteilung 
von Verantwortung gewinnen, ebenso die Weiterfuhrung 
dieser Idee in sogenannten „objektorientierten" Betriebs- 
systemen (beispielsweise [K+81, Y + 90, B + 95, Ass96] 
u.v.m.), aber auch die auf bestimmten festen Mechanismen 
aufgebauten Betriebssysteme (z.B. auf Capabilities basie- 
rend [NW77, T+90]). Auch das im Software-Engineering 
oft zitierte Lokalitats-Prinzip als Mittel zur Strukturierung 
von Systemen beruht letztlich auf der Aufteilung von Ver- 
antwortung. Es gibt unzahlige weitere Beispiele. 

23.1 Kontrollflusse 

Ein sequentieller Kontrollfluss (thread, konzeptuelle Be- 
schreibung bereits in [DH66]) lasst sich als AktivitatstraV 
ger charakterisieren, der von auBen beobachtbar nur eine 
sequentieile Folge von (Maschinen-)Operationen ausfuhrt. 
Kontrollflusse sind bereits in [Dij68] zur Strukturierung von 
Verantwortung in Betriebssystemen benutzt worden; diese 

23 Wie [Mey88] und viele andere Autoren bemerken. verlaufen die 
Haupt-Auseinandersetzungen um Strukturierungs-Kriterien hauptsiichlich 
entlang der Demarkations-Linien „Strukturierung nach Daten" versus 
..Strukturierung nach Kontrollfluss" (vgl. [Par72]). Die von mir propagier- 
te Strukturierung nach Verantwortungsberelchen rfimmt demgegenuber ei- 
ne Ubergeordnete Perspektive ein: Verantwortung ist fast immer an Dalen- 
strukturierung und nur selten an Kontrollflusse gekoppelt. Die Abstrakti- 
onsebene ist jedoch vonkonkreten Datenstrukturen abgekoppelt: bei holier 
Abstraktionsebene kann sich Verantwortung auf Mengen von Datenstruk- 
turen erstecken. im anderen Extrem aber auch bis auf Teil-Datenstrukturen 
verfeinert werden. 



feste Verbindung von Kontrollfliissen mit der Verantwor- 
tung fiir bestimmte Bereiche wird in der vorliegenden Ar- 
beit jedoch aufgegeben. Kontrollflusse konnen zur Struktu- 
rierung von Verantwortung benutzt werden, jedoch gibt es 
in der hier vorgestellten Architektur keine notwendigerwei- 
se feste Verbindung mit Verantwortungsbereichen (wobei 
im Einzelfall auch feste Verbindungen hergestellt werden 
konnen, aber nicht miissen). 

Kontrollflusse werden als volikommen unabhangig von 
konventionellen Konzepten wie Prozesse oder Mechanis- 
men wie Schutzbereiche angesehen. Im Gegensatz zu an- 
deren Arbeiten werde ich den Begriff des Prozesses vermei- 
den, da es fur ihn mehrere verschiedene Definitionen gibt 24 . 
Seit der Wiederentdeckung der Schutzbereiche (spheres 
of protection [DH66], protection domains [NW74, CJ75]) 
im Kontext so genannter S ingle- Address-Space-Systeme 
[C+94, Ros94] (vgl. Beschreibung und Schutzmechanis- 
men von CTSS in [BPS 81]) hat sich die Bedeutung der Be- 
griffe weiter verkompliziert. Ich beschranke mich daher auf 
die Begriffe Kontrollfluss und Schutzbereich. 
^Jejier Kontrollfluss hat zu jedem Zeitpunkt einen ein- 
jlflbestimiTiten Kontext. Die Bedeutung dieses Kontexts 
V l om jeweils gewahlten Ausfuhrungs-Modell ab: bei 
d^Wmulation eines „Prozesses" ware dies beispielsweise 
das Prozessabbild, in dem sich der Kontrollfluss befindet 
und seine Operationen ausfuhrt; im Fall von Single-Space- 
oder Hybridsystemen ware dies der jeweils aktuelle Schutz- 
bereich. 

Kontexte konnen auf Anforderung gewechselt werden 
(vgl. [DH66]): ein Kontrollfluss wechselt damit in einen an- 
deren „Prozess" bzw. in einen anderen Schutzbereich, der 
sich ggf. auch auf einem anderen Rechner be^nden kann. 
Hiervon sind zwei verschiedene Varianten denkbar: eine 
ohne Abspeichern des alten Kontextes im Stile von Wech- 
seln zwischen Coroutinen, die andere mit Abspeichern aller 
durchlaufenen Kontexte in Form eines Stapelspeichers mit 
der Moglichkeit zur RUckkehr in einen fruheren Kontext 
ahnlich einem synchronen RPC oder LRPC Eine Konse- 
quenzaus der Wechselmoglichkeit ist, dass die Anzahl der 
„Prozess" oder Schutzbereich tatigen Kontroilflus- 
^namisch andern und auch zeitweise zu Null wer- 
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Man sollte sich vor Augen halten, dass Schutzbereiche 
einen Mechanismus zur Durchfuhrung und Uberwachung 
von Sicherheits-Konzepten darstellen, wohingegen Verant- 
wortungsbereiche ein davon prinzipiell unabhangiges logi- 
sclies Konzept zur Strukturierung eines Systems darstellen. 
Die Abbildting von Verantwortungsbereichen auf Schutz- 
bereiche ist eine Frage von Strategien und kann auf unter- 
schiedliche Weise, ggf. auch dy namisch zur Laufzeit, gelost 
werden. 

Kontrollflusse werden in konventionellen Architekturen 
als eigenstandige Abstraktion betrachtet. Da ihre Imple- 
mentierung in einem eigenen Baustein erfolgen kann, ist die 
Behandlung als separate Abstraktion nicht unbedingt not- 

24 Heute wire! unter Prozess meist ein in Ausfuhrung befindiiches Pro- 
gramm verstanden, das eine Menge von Ressourcen allokiert hat und min- 
destens einen Kontrollfluss (thread) besitzt. In den 1960er und I970er Jah- 
ren waren teilweise noch einfachere Definitionen Ublich, die mit dem heu- 
tigen Begriff des Kontrollflusses (thread) zusam men fallen. 



wendig. Wegen ihrer dynamischen Durchdringung der ge- 
samten Infrastruktur kann man sie jedoch als Hilfsabstrak- 
tion bezeichnen. 

Im Folgenden betrachten wir unser Betriebssystem zur 
Vereinfachung standardmaBig (sofem nicht ausdriicklich 
abgewichen wird) weder mit Hilfe von Prozess- oder 
Schutzbereichen, noch von Kontrollfliissen oder anderen 
Aktivitatstragern, sondern ausschliefilich auf Basis der je- 
weils zu implementierenden und zu verantwortenden Funk- 
tionalitat. 

2.3.2 Schnittstellen-Mechanismen 

Die Gesamtverantwortung eines Betriebssystem s kann auf 
sehr viele verschiedene Arten aufgeteilt werden; die von 
mir bevorzugten Aufteilungs- Strategien werden in Ab- 
schnitt 2.4 naher dargestellt. Jegliche Art von Aufteilung 
von Verantwortung fuhrt dazu, dass Modularisie rungs- 
Grenzen in ein System eingefuhrt werden, die bei forma- 
lisierter Darstellung auch als Schnittstellen-Instanzen be- 
zeichnet werden. 

Durch die Einfuhrung von Schnittstellen-Instanzen zur 
Begrenzung von Modul-Instanzen entsteht eine Unterschei- 
dung der durchzufuhrenden Operationen in Aufrufer- und 
Bear&e/ter-Instanzen, die jeweils immer nur relativ zu einer 
festen Schnittstelle so bezeichnet werden; dieselbe Instanz 
kann bezuglich verschiedener Schnittstellen gleichzeitig 
als Aufrufer oder Bearbeiter fungieren. Bei verschiedenen 
unterscheidbaren. Operationen konnen diese Rollen unter- 
schiedlich verteilt sein, beispielsweise kann eine Modul- 
Instanz A gegenuber der Instanz B bei der Durchfuhrung 
der Operation op x als Aufrufer, bei op 2 als Bearbeiter fun- 
gieren. 

Als Mechanismen zur Weitergabe der Verantwortung ei- 
ner Aufrufer- an eine Bearbeiter-Instanz kommen mehre- 
re bekannte und bewahrte Methoden in Betracht. Beispiels- 
weise kommen hierfur in Frage, in der Reihenfolge fallen- 
den Overheads bzw. fallender Kosten: 

• RPC (remote procedure call) [BN84, TA90] 

• LRPC (local / lightweight RPC) [B+90] 

• IndirekteProzeduraufrufe 

• Direkte Prozeduraufrufe 

• Makro- oder Inline-Prozeduraufrufe 

Diese Beispiel-Mechanismen eignen sich teilweise nur fur 
die synchrone Weitergabe von Verantwortung, bei der die 
Aufrufer-Instanz bis zur Beendigung der Bearbeitung war- 
ten muss. Bei asynchroner Weitergabe der Verantwortung 
entsteht implizit ein weiterer logischer Kontrollfluss 25 , Die 

"Es muB nicht unbedingt ein tatsachlich neuer Kontrollfluss im phy- 
sischen Sinne entstehen: Bei der Implementierung von Bausteinen als 
Server-Prozesse (vgl. [Han70, Hoa78J) bleibt die Anzahl physischer Kon- 
trollflusse im Regelfall konstant Die im Nachrichtensystem gepufFerte 
Nachricht stellt im logischen Sinne einen logischen Kontrollfluss dar, der 
von einem physischen Kontrollfluss simuliert wird, sobald die Nachricht 
bearbeitet wird. Solche Systeme sind fur den Fall gebaut, dass mehr logi- 
sche als physische KontrollflQsse auftreten kfinnen. und beschr3nken daher 
die theoretisch mogliche maximale Parallelitat auf kunstliche Weise. Falls 
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asynchrone Weitergabe von Verantwortung per Prozedu- 
raufruf ist daher nicht ohne Einbezug des jeweils verwen- 
deten KontroIIfluss-Konzeptes (siehe Abschnitt 2.3.1) mog- 
lich. • ' 

Man sollte sich vor Augen halten, dass die Frage nach 
einer parallel oder sequentiell iibertragenen Verantwortung 
prinzipiell von der Aufteilungsstrategie in Module unab- 
hangig ist und daher als eine Frage der konkreten Im- 
plementierungsstrategie der Module gesehen werden kann, 
auch wenn die zugehorigen Mechanismen nicht vollkom- 
men (wenn auch weitgehend) voneinander unabhangig 
sind. 

Universelle Generizitat relativ zu den oben genannten 
synchronen Mechanismen laBt sich direkt durch einheitli- 
che Verwendung von synchronem RPC auf alien Ebenen 
des Systems erzielen, da dieser die Semantik der anderen 
Mechanismen als Spezialfall mit umfasst. Dies wiirde je- 
doch die Performanz eines lokalen Rechners in unakzepta- 
bler Weise verschlechtern. Zur Erzielung universeller Ge- 
nerizitat schlage ich daher eine Erweiterung der bereits in 
[Str78] dargestellten Methode vor: 

Man wahle eine einheitliche und bequeme syntaktische 
Representation, beispielsweise die Prozeduraufruf-Syntax 
der verwendeten Programmiersprache. Die Bindung von In- 
stanzen dieser Kohstrukte an einen der obigen Mechanis- 
men erfolgt dann entweder zur Ubersetzungszeit des jewei- 
ligen Moduls, oder falls moglich auch zur Laufzeit bei der 
Instantiierung eines Moduls (die Unterscheidung zwischen 
indirekten / direkten / Inline- Aufrufen ist mit heute gangiger 
Standard-Technik 26 nicht ohne weiteres zur Laufzeit mog- 
lich). 



2.33 Abgrenzung von Verantwortung durch 
Kapselung 

Im Software-Engineering ist lange bekannt, dass die Priif- 
barkeit, Wartbarkeit und viele andere Eigenschaften von 
Modulen verbessert werden, wenn die Schnittstellen mog- 
lichst „dunn" sind und moglichst wenig Information u'ber 
die innere Struktur der Implementierung preisgeben (Prin- 
zip der Verbergung von Information, vgl. [Par72]). 

Dies bedeutet zum einen, dass Schnittstellen stets offen- 
gelegt werden mussen, wobei die Schnittstelle zwischen 
Bausteinen eine von der Architektur vorgebene Form ha- 
ben muss, an die sich die Implementierer von Bausteinen 
halten mussen. Alles andere ist als lokale Variablen eines 



jedoch geniigend physische KontrollflQsse vorhanden waren, urn alle ein- 
gehenden Nachrichten eines Bausteins sofort bearbeiten zu kOnnen, ware 
die Pufferung von Nachrichten iiberflUssig. In der Praxis ist die Bevorra- 
tung von KontrollflUssen mit hohem Overhead verbunden; wenn man des- 
wegen die Bevorratung von KontrollflUssen durch dynamische Erzeugung 
und Destruktion von KontrollflUssen (vgl. historisches Beispiel [Opl65]) 
ersetzt, landet man wieder beim allgemeinen asynchronen Modell, dessen 
Parallelitatsgrad theoretisch nicht beschrSnkt ist. 

26 Mittels dynamischer Code-Generierung, wie sie z.B. bei Java bei 
der Umsetzung von Byte-Code in Zielplattform-Maschinencode eingesetzt 
wird, kann man prinzipiell auch die Bindung von Prozeduraufrufen zu 
alien genannten Mechanismen zur Laufzeit durchfilhren. Es ware ein in- 
teressantes Forschungsprojekt, dies nicht nur aus dem Quelltext oder aus 
Zwischencode-Darstellungen heraus. sondern auch aus bereits vollstandig 
compiliertem Code heraus (der ggf. Zusatzinformationen enthalten mtis- 
ste) zu bewerkstelligen. 



Baustems zu betrachten. Die interne Realisierung von Bau- 
steinen darf jedoch bzw soil moglichst andere Baustein- 
Instanzen als lokale Variablen benutzen (wobei wiederum 
keine „schwarzen Schnittstellen" eingefuhrt werden dur- 
fen), so dass sich insgesamt eine baumartige Lokalitats- 
Hierarchie ergibt, die von der hierarchischen Struktur der 
auBerlichen Baustein-Verdrahtungen unabhangig ist. Die 
Verantwortung fur den Einsatz und den Betrieb von lokalen 
Baustein-Instanzen liegt beim Implementierer eines Bau- 
steins. Die Tatsache der Benutzung von lokalen Baustein- 
Instanzen ist dabei von auBen nicht sichtbar. 



2.4 Zerlegungs- und 
onsstrategien 



Rekombinati- 



2.4.1 Zerlegung der zu losenden Aufgaben 
in moglichst wenige universelle Ele- 
mentarteile 

Bei der Problemanalyse propagiere ich die Anwendung ei- 
ner einfachen Methode: es ist zu fragen, wie generische 
Funktionalitat (vorzugsweise in Form von universeller Ge- 
nerizitat) in moglichst wenige, aber universelle Elementar- 
funktionalitat zerspalten werden kann. Aus dieser Elemen- 
tarfunktionalitat ergeben sich dann die Elementaroperatio- 
nen als Umsetzung in ein von-Neumann-Maschinenmodell, 
die im Pseudo-Code einer imperativen Programmiersprache 
notiert werden. 



2.4.2 Orthogonalitat und Rekombinierbar- 
keit von Elementaroperationen 

Im Idealfall sollten die Elementaroperationen die Eigen- 
schaft der Orthogonalitat besitzen, d.h. keine der Elemen- 
taroperationen sollte sich durch Kombination anderer Ele- 
mentaroperationen simulieren lassen. 

Eine Zerspaltung in orthogonale Elementaroperationen 
kann dazu fuhren, dass sehr kleine, nach ublichen MaBsta- 
ben „triviale" Elementaroperationen entstehen, die in der 
Praxis selten oder nie als alleinstehende Operationen ge- 
nutzt werden, sondern haufig nur in Kombination mit ande- 
ren Elementaroperationen. Entwerfer haben oft die konkre- 
te programmiersprachliche Representation einer Elerrtenta- 
roperation als Prozeduraufruf oder RPC im Hinterkopf und 
schrecken daher oft vor dem Overhead einer solchen „tri- 
vialen" Zerlegung zuruck. Das Problem des Overheads laBt 
sich jedoch weitgehend vermeiden, wenn man die systema- 
tische Rekombination von Elementaroperationen als eige- 
nes Grundkonzept einfiihrt. 

Wenn die Rekombination orthogonaler Elementaropera- 
tionen bei der Bearbeiter-Instanz der Prozedur- oder RPC- 
Aufrufe erfolgt, ergibt sich nur ein geringer bis verschwin- 
dender Overhead im Vergleich zur direkten Implementie- 
rung jeglicher Kombination. Der Vorteil der Zerlegung be- 
steht jedoch darin, daB im Regelfall nur der Program mcode 
fur die wenigen Elementaroperationen implementiert wer- 
den muss, nicht dagegen fur alle vorkommenden Kombina- 
tionen, die oft wesentlich zahlreicher ausfallen. 
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Das Problem der „. 
Wollmilchsau" 
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GroBere Softwaresy steme, die uber iangere Zeit benutzt und 
erweitert wurden oder die fur sehr groBe Anwendungsfelder 
und -bandbreiten ausgelegt wurden, zeigen oft ein Phano- 
men auf, das salopp mit „Featuritis" bezeichnet wird. Sol- 
che Alleskonner haben manchmal Schwierigkeiten, ganz 
einfache grundlegende Aufgaben auf einfache und effizien- 
te Weise zu erledigen. Die Softwarestruktur ist im Vergleich 
zu einfachen Programmer die nur die Grundaufgaben ab- 
decken, oder im Vergleich zu Spezialisten meist deutlich 
aufgeblaht (Overhead) und schwerer zu durchschauen. 

Um dieses Problem handhabbar zu machen, schlage ich 
die Verwendung unterschiedlicher Modelle vor, zwischen 
denen moglichst eine hierarchische Inklusions-Beziehung 
in dem Sinne herrschen sollte, daB man ein Modell als Spe- 
zialfall eines anderen Modells betrachten kann; oft ist das 
weniger machtige Model] auch einfacher. Als Beispiel hier- 
f|^rden in Abschnitt 3.2 verschiedene Zugriffs-Modelle 
^ ;lM ter wie singleuser oder multiuser behandelt 

Bine Nest ~ od&r Baustein-Implementierung braucht nicht 
unbedingt alle moglichen Modelle zu unterstiitzen. So kann 
man beispielsweise mit der Implementierung der einfa- 
cheren Modelle beginnen und diese erst spater und bei 
Bedarf auf die komplizierten Modelle erweitern oder fur 
die kompizierteren Modelle alternative Implementierungen 
vornehmen (deren hoheren Kosten miissen dann von dsn 
Verwendern der einfacheren Model I -Vari ante nicht bezahlt 
werden). Welche Modelle von einer Nest- oder Baustein- 
Implementierung im Einzelfall unterstiitzt werden, wird als 
Kompetenz {competence) dieser Implementierungs-Instanz 
bezeichnet. Demgegenuber steht das Verhalten {habit) ei- 
ner konkreten Aufrufer-Instanz; damit werden die Anforde- 
rungen an die Kompetenzen der Implementierungs-Instanz 
bezeichnet. 

DieKompetenzen einer Implementierungs-Instanz mtis- 
s^jjL^Verhalten einer Aufrufer-Instanz kompatibel sein. 
MSj»petenzen und das Verhalten von Nest- und 
Ba^^T-Instanzen werden je Baustein-Art in Form von At- 
tributen angegeben. Die Kompatibilitat kann dann bei der 
Verdrahtung konkreter Baustein-Instanzen automatisch ge- 
testet werden, wobei inkompatible Verdrahtungen zuriick- 
gewiesen werden. 

Attribute konnen entweder statisch oder dynamisch sein: 
statische Attribute eines Baustein-Typs andern sich nie (sie 
hangen nur vom Baustein-Typ oder der gewahlten Imple- 
mentierung ab), dynamische Attribute hangen von der kon- 
kreten Instantiierung und/oder von der Verdrahtung mit an- 
deren Bausteinen ab, andern sich jedoch nicht wahrend der 
Lebensdauer einer Baustein-Instanz. Werte, die sich wah- 
rend der Lebensdauer einer Baustein-Instanz andern kon- 
nen, stellen keine Attribute dar, sondern gehoren zum Zk- 
stand der Baustein-Instanz. 

Attribute werden insbesondere zur Unterscheidung ver- 
schiedener Modelle eingesetzt und in Schreibmaschi- 
nenschrif t gesetzt. 



Die Grundidee der Automatisierung wird seit Jahrhunder- 
ten erfolgreich zur Reduktion von Aufwand und Kosten ein- 
gesetzt. 

Im Kontext der hier vorgestellten Architektur bedeutet 
Automatisierung, dass vorzugsweise von deskriptiven Me- 
thoden Gebrauch gemacht wird, um einen Mechanismus 
selbsttatig auszulosen, der immer wiederkehrende Vorgan- 
ge selbsttatig bearbeitet. 

Die Implementierung vieler Automatismen ist eine Fra- 
ge von konkreten Strategien, die in speziellen Bausteinen 
(strategy^*) Iokalisiert werden sollten (vgl. Abschnitt 
4.2.2). 

Zur Erstellung von Bausteinen sind weitere Automa- 
tismen von groBem Nutzen, die iiber den Funktions- 
umfang ublicher Werkzeuge wie Compiler oder Debug- 
ger hinaus gehen sollten. Viele mit den hier vorge- 
stellen (Schnittstellen-)Mechanismen zusammenhangende 
Konstruktionsvorgange lassen sich automatisieren. 

Die in Abschnitt 2.3.2 vorgestelle spate Bindung an kon- 
krete Aufrufmechanismen kann beispielsweise auf folgende 
Weise automatisiert werden: 

Der Programmierer gibt ein statisches Baustein-Attribut 
an, mit dem er sein Denk-Modell deklariert, mit dessen Hil- 
fe er den Programmcode entwickelt hat. Das Attribut kann 
folgende Werte annehmen: 

code_nolock Der Programmierer tut so, als gabe es nur 
einen einzigen Kontrollfluss, der den Baustein 
betreten durfte 27 ; er kummert sich also uber- 
haupt nicht um Parallelitat. Dies hat zur Folge, 
dass aus Sicherheitsgrunden niemals ein wei- 
terer Kontrollfluss den Baustein betreten darf, 
selbst wenn der bereits eingetretene Kontroll- 
fluss eine lange dauernde blockierende Opera- 
tion aufruft. 

code_monitor Wie vorher, nur ist der Programmierer 
sich immerhin der Tatsache bewusst, dass meh- 
rere Kontrollflusse vorkommen konnen. Jeder 
Aufruf der Blockierungs-Operation wait (sie- 
he Abschnitt 3.3.2) fuhrt automatisch zu einer 
Entblockierung des Zugriffsschutzes gegen- 
uber anderen Kontrollflussen, Der Program- 
mierer ist fur die Beachtung der damit verbun- 
denen Effekte verantwortlich; insbesondere ist 
ihm bewusst, dass kritische Abschnitte genau 
an der Stelle einer wait-Operation aufgeho- 
ben werden (analog zum Monitor-Konzept). 

code_reentrant Der Programmierer ist sich dessen 
bewusst, dass mehrere Kontrollflusse den Bau- 
stein asynchron betreten konnen. Er ist selbst 
fur die Sicherung kritischer Abschnitte und fur 
das Setzen von Locks verantwortlich. % 

Ein zu syntaktischer Analyse fahiger und die Schnittstellen- 
Konventionen kennender Quelltext-Praprozessor extrahiert 

27 Auch im singleuser-Modell (Abschnitt 3.2) kannen asynchrone 
Kontrollflasse durch notify_*-Operationen (Kapitel 5) entstehen. 
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diesen Attribut-Wert aus demrjuelltext und generiert bei 
Bedarf (je nach eingestelltem Aufruf-Mechanismus) auto- 
matisch Lock-Operationen zur Klammerung kritischer Ab- 
schnitte, Fallunterscheidungs-Kontrollstrukturen zum De- 
multiplexen eingehender (L)RPC-Aufrufe, und so weiter. 
Auf diese Wejse laBt sich jedes Program mierm ode! 1 mit je- 
dem Schnittstellen-Mechanismus kombinieren 28 ; bei Ver- 
wendung.von statischen oder Inline-Prozeduraufrufen wer- 
den durch den Praprozessor mehrere Quelltexte verschie- 
dener Bausteine zu einem einzigen Kombi-Baustein fest 
zusammengeschweisst 29 . Bei geeigneter sorgfaltiger Kon- 
struktion und Verwendung gut optimierender Compiler laBt 
sich durch Inline-Prozeduraufrufe jeglicher Schnittstellen- 
Aufwand fast vollstandig eliminieren; dies ist insbesondere 
zum Anschluss von Pruf- und Sicherheits-Bausteinen oder 
kleineren Trivial-Bausteinen niitzlich. 
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2.7 Zugriffsrechte und Schutzmecha- 
nismen 

2*7.1 Grundlegende Betrachtung 

Die Rechteverwaltung in Betriebssystemen basiert bei 
den meisten praktisch eingesetzten Modellen [Lan81] auf 
Rechte-Relationen, die Subjekte und Objekte miteinander 
in Beziehung setzen; typischerweise lassen sich derartige 
Relationen zwischen Subjekten und Objekten tabellarisch 
darstellen. 

Ich mochte fur die Rechteverwaltung einen Ansatz vor- 
stellen, der sich bei geeigneter Interpretation ebenfalls als 
Subjekt-Objekt-Schema auffassen lapt, dabei jedoch belie- 
bige Dinge als Subjekte bzw Objekte auffassen kann. 

Zunachst ist zu fragen, was uberhaupt zu schutzen ist, 
Hierauf sind mehrere Antworten moglich. Eine moglichst 
allgemeine Antwort ist, dass es sich urn Informational han- 
delt, die zu schutzen sind. Dies umfasst die klassischen 
Objekte (die auf jeden Fall Informationstrager darstellen), 
bedeutet aber nach meiner Ansicht etwas mehr. In einem 
Betriebssystem gibt es Informationen, die nicht unbedingt 
(in Form zugreifbarer Datenobjekte vorliegen mussen. Ty- 
pische Beispiele hierfur sind die Menge aller moglichen 
Schlusselwerte eines geheimen kryptographischen Schliis- 
sels, oder die Rechte anderer Subjekte (die nicht unbedingt 
explizit reprasentiert zu sein brauchen), oder die Kompeten- 
zen oder das Verhalten anderer Subjekte, oder andere Sub- 
jekte schlechthin; Subjekte konnen in anderem Kontext wie- 
derum Objekte darstellen. Informationen uber Objekte las- 

2lt Fal!s man code_nolock mit (L)RPC kombiniert, braucht man 
selbstverstandlich keine Lock-Operationen einzufiigen, da es dann ja nur 
einen einzigen (automatisch eingefugten und bei der Initialisierung gest- 
aiteten) Kontrollfluss gibt; durch einheitliche Verwendung dieser Konfi- 
guration bei alien Bausteinen erhalt man das klassische CSP-Modell, das 
zu Zwecken der Fehlersuche und -Eingrenzung deutliche Vorteile bringt 
ansonsten aber die potentielle Parallelitat unnotig einschrankt. Die Kom- 
bination von code_reentrant mit (L)RCP stellt insofern eine gewisse 
Verschwendung dar. 

29 Hierbei sind (interne) Bezeichner (bzw. zu internen Bezeichnern 
werdende ursprunglich 6ffentliche Bezeichner) mit einem Versions- 
Kennzeichen zu veriindern, urn die mehrfache Instantiierung desselben 
Baustein-Typs in einem Kombi-Baustein moglich zu machen. Details 
den in dieser Arbeit nicht behandelt. 



sen sich ggf. auch durch Schlussfolgem otexAbleiten erhal- 
ten. Ich schlage deshalb vor, statt der Begriffe Subjekt und 
Objekt andere Begriffe zu verwenden, die durch die folgen- 
den Uberlegungen begriindet sind: 

Der Zweck eines Betriebssy stems ist die Ausfuhrung 
von Operatiofien\ dies geschieht in der hier vorgestell- 
ten Architektur (vgl; Abschnitt 3.2 und Kapitel 6) durch 
Bearbeiter-histanzen im Auftrag von Aufrufer-Instanzen. 
Da eine Aufrufer-Instanz wiederum im Auftrag mehre- 
rer anderer Aufrufer-Instanzen handeln kann, ergeben sich 
zwei Fragestellungen: 

1. Wer soil naturlicherweise das Subjekt darstellen, das 
einen bestimmten Auftrag veranlasst? 

2. Wer soli naturlicherweise das Objekt darstellen, das 
den Auftrag ausfuhren soil? 

Die erste Frage ist auf verschiedene Weisen beantwort- 
bar. Daher schlage ich die Einfuhrung eines anderen Be- 
griffes statt „Subjekt" vor, namlich das Mandat (mandate). 
Operationen geschehen grundsatzlich aufgrund eines Man- 
dates; im allgemeinen kann dabei eine Instanz (bzw ein 
Subjekt in bisheriger Terminologie) mehrere verschiedene 
Mandate wahrnehmen; auch kann es vorkommen, dass ver- 
schiedene Instanzen aufgrund des gleichen Mandats han- 
deln. Beispiele hierfur finden sich in der realen Welt im 
Rechtswesen: ein und derselbe Rechtsanwalt kann gleich- 
zeitig verschiedene Mandate fur verschiedene Mandanten 
wahrnehmen. Ein Mandant kann verschiedene Mandate 
gleichzeitig an verschiedene Rechtsanwalte oder an den 
gleichen Rechtsanwalt vergeben. Er kann dasselbe Mandat 
aber auch an mehrere Rechtsanwalte gleichzeitig vergeben, 
beispielsweise bei Anwalts-Gemeinschaften oder Kanzlei- 
en. Mandate konnen vertreten oder weitergereicht werden. 
Im Rechtswesen konnen auch Unter mandate vergeben und 
aufgeteilt werden; von der letzteren Moglichkeit habe ich 
hier wegen der damit verbundenen Komplexitat und Fol- 
geeffekte vorlaufig Abstand genommen 30 . Die Menge al- 
ler moglichen Mandate sollte durch einen abstrakten Daten- 
typ mit ausreichend grossem Wertevorrat 31 dargestellt wer- 
den. Mandate haben keine festliegende Interpretation, son- 
dern werden lediglich zwischen Baustein-Instanzen weiter- 
gereicht. Alle Operationen auf Mandaten wie z.B. ihre Er- 
zeugung gehoren somit zu den Strategien, die der Imple- 
mentierer eines Bausteins selbststandig bestimmen kann. 
Mandate stellen somit eine weitere Hilfsabstraktion dar. 

Die zweite Frage ist im Kontext der hier vorgestellten Ar- 
chitektur relativ schnell zu beantworten: ein Objekt ist auf 
jeden Fall die Ausgangs-Nest-Instanz, an die der zu bear- 
beitende Auftrag gerichtet wird. Diese Nest-Instanz zerfallt 
jedoch nicht nur in Unterobjekte wie z.B. einzeln adressier- 
bare Bytes, sondern stellt auch wegen der eingangs aufge- 
fuhrten Problematik nic ht alle Informationen dar, die nach 

30 Ob und in welchen Fallen Untermandate vorteilhafte Beschreibungen 
darstellen, dUrfte eine interessante zu untersuchende Frage sein. Struktu- 
rell sind Untermandate zwarShnlich zu Gruppen vOn Subjekten, die Erzeu- 
gung von Untermandaten kann jedoch rein dynamisch zur Laufzeit gesche- 
hen, die wiederum in weitere Untermandate zersplittert werden konnten. 
Ob und wie weit solche Modelle vorhersagbares und intuitiv fur Menschen 
leicht begreifbares Verhalten zeigen, muss noch untersucht werden. 

3 Nach heutigen MaBstaben sind hierzu mindestens 64 Bit reservieiier 
Platz erforderlich. 
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• Moglichkeit geschutzt werden soIlten/Eie folgende Be- 
griffsbildung kommt diesem Ziel etwas naher: 

Zu schutzen ist die Ausfuhrung von Operationen. Die 
Menge aller ausfuhrbaren Operationen wird Operationen- 
menge genannt; dies sind alle moglichen Kombinationen 
von Operations-Bezeicjinern mit ihren Eingabe-Parameter- 
Werten, oder in anderen Wbrten die Vereinigung aller 
kartesischen Produkte aller Operationsnamen mit ihren 
Parameter- Wertemengen (egal wie viele es sein mogen). 
Auch wenn man die Menge aller moglichen Parameter- 
Versorgungen als endlich betrachtet (indem man bei- 
spielsweise die Menge aller vorkommenden Zeichenketten- 
Parameter beschrankt), ist die Operationen menge i.a. sehr 
gro8. Eine dazu aquivalente Darstellung ist die Beschrei- 
bung als Menge aller moglichen Bitstrings, die in einem 
generischen Operations-Nest (vgl. Kapitel 6) auftreten kdn- 
nen. 

Eine Schutzmenge ist eine Teilmenge der Operationen- 
menge eines gegebenen Systems. Schutzmengen sind als 
Mengen aller (im Sinne irgendeines ausserhalb definier- 
tenZulassigkeits-Begriffes) zulassigen Operationen zu in- 
fctieren. 

Spezifikation von Schutzrechten 

Der Begriff der Schutzmenge vereinfacht die Abstraktion 
irgendwelcher Schutz- und Zulassigkeitsbegriffe auf ma- 
thematisch sehr einfach fassbare und hochgradig flexible 
Weise 32 . Da Schutzmengen i.a. zu groB fiir eine tabella- 
rische Darstellung sind, braucht man irgendwelche Spe- 
ziflkationsmechanismen, die sie beschreiben. Der Zweck 
eines Spezifikationsmechanismus besteht einerseits darin, 
eine Schutzmenge fur menschliche Leser ve'rstehbar und 
nachvollziehbar komprimiert darzustellen, und andererseits 
das Enthaltens-Problem der Schutzmenge speichereffizient 
auf Rechnern auswertbar zu machen. 

Als Spezifikationsmechanismen kommen sehr viele kon- 
krete Realisierungen (z.B. passend eingeschrankte Pradi- 
katenlogiken oder andere Kalkule) in Betracht, deren Dis- 
k "PS5 den Rahmen dieser Arbeit sprengen wurde. Es 
sibM^e weiteres auch militarische Schutzmodelle (vgl. 
[WCy oder mehrere voneirtander unabhangige Schutz- 
mof^re, gleichzeitig einsetzbar. 

2.7.3 Prufung von Schutzrechten 

Die Prufung von Schutzrechten kann in speziellen Priif- 
Bausteinen check_* erfolgen, die sich prinzipiell an be- 
liebigen Stellen einer Baustein-Hierarchie einfugen lassen. 
Dort weisen sie die im Sinne des jeweiligen Schutzmodells 
unzulassigen Operationen zuriick. Falls man in speziellen 
Anwendungsbereichen wie z.B. Echtzeit-Steuerungen kein 
Schutzmodell benotigt, kann man auf die Instantiierung von 
check_*-Bausteinen vollkommen verzichten und damit 
jeglichen Overhead einsparen. 

32 Das klassische Konzept der Rechte-Tabellen laBt sich als Spe- 
zialfall einer Schutzmenge darstellen: man bilde die Menge al- 
ler Tripel (op,sub j ec t,ob;j ec t), die durch eine Subjekt-Objekt- 
Zuordnungstabelle beschrieben wird, und fOlle gegebenenfalls durch die 
Tablle nicht beschriebene weitere Parameter-Komponenten der Operatio- 
nen mit der Menge aller mfiglichen Werte auf. 
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Die konkrete Realisierung eines Schutzmechanismus ist 
eme Frage der Strategie, an welchen Stellen welche Ar- 
ten von Priifungen auf Basis welcher Mandate durchgefuhrt 
werden sollen. Zu beachten ist, dass zur Laufzeit beliebige 
Baustein-Instanzen neu instantiiert und neue Verdrahtungen 
erzeugt werden konnen, mit denen ein festes Schutzkonzept 
u.U. umgangen werden kann. Beim Einsatz kompositori- 
scher Generizitat steckt ein Teil der im System vorhandenen 
Informationen in der Verdrahtung der Bausteine, die hoch- 
gradig flexibel und dynamisch anderbar ist. Zur Losung die- 
ses Problems mussen die Instantiierungs-Operationen von 
control-Instanzen (siehe Abschnitt 4.2.1) in das jewei- 
Iige Schutzkonzept mit einbezogen und iiberwacht wer- 
den. Zur mathematischen Beschreibung der dynamischen 
Eigenschaften von Baustein-Netzwerken eignet sich even- 
tuell die Menge aller moglichen Baustein-Konfigurationen, 
die durch control erzeugbar sind. 

2.7.4 Sicherstellung von Schutzrechten 

In der Literatur Uber Schutzmechanismen in Betriebssyste- 
men werden vor allem zwei Mechanismen zur Sicherstel- 
lung eines Schutzkonzepts verwendet: 

1. Sicherstellung durch Zugriffsbeschrankung mittels ei- 
nes Typkonzepts einer hoheren Programmiersprache 

2. Sicherstellung durch die MMU 

Typkonzepte von Programmiersprachen haben zwar den 
geringsten Laufzeit-Overhead, bieten jedoch i.a. nicht das 
MaB an Sicherheit gegen Umgehung durch boswillige An- 
griffe, wie dies MMU-Hardware ermoglicht, indem sie Zu- 
griffe auf fremde Schutzbereiche physikalisch unterbindet. 

Im Prinzip lassen sich beide Mechanismen in der hier 
vorgestellten Architektur einsetzen, wobei Mechanismus 1 
durchaus Vorteile bei der Erhohung der Zuverlassigkeit ei- 
nes Systems gegen versehentliche Fehlfunktionen mit ge- 
ringem Overhead besitzt; wirkliche Sicherheit gegen bosar- 
tige Angriffe bietet jedoch nur der Mechanismus 2, 

Die Realisierung eines Schutzmodells ist daher von der 
Einteilung des Betriebssystems in Schutzbereiche abhangig 
(siehe Abschnitt 4.2). Im einen Extremfall kann das gesam- 
te System in einem einzigen Schutzbereich ablaufen, im an- 
deren Extremfall kann jede Baustein-Instanz in einem ei- 
genen Schutzbereich ablaufen; es sind beliebige Zwischen- 
stufen moglich. Sinnvollerweise sollten Zugriffsrechte vor 
allem an den Grenzen zwischen Schutzbereichen gepruft 
werden, sofern dieser Auf wand in Kauf genommen werden 
soil. 



2.8 Performanz-Fragen 

Nicht nur in der Literatur wird der Performanz eines Sy- 
stems ein hoher Stellenwert eingeraumt. Das Ziel hoher 
Performanz kann gelegentlich mit anderen Zielen in Wider- 
spruch stehen. Durch konsequente Anwendung der Tren- 
nung zwischen Mechanismen und Strategien laBt sich die- 
ser Zielkonfiikt jedoch in vielen Fallen vermeiden, wenn 
man beim Entwurf der Mechanismen auf deren performante 
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Implementierbarkeit achtet (die tatsachlich erzielte Perfor- 
manz hangt jedoch u.a. von den Kenntnissen, Fahigkeiten 
und Methoden des Implementierers ab 33 ). 

2.8.1 Performanz von Elementaroperationen 

In Abschnitt 2.4.2 wurde bereits die systematische Re- 
kombi nation von Elementaroperationen aus methodischen 
Grunden heraus motiviert. Performanz stellt ein weiteres 
Motiv dar. 

Aufrufer benutzen Elementaroperationen haufig in Bun- 
deln, d.h. in sukzessiven Folgen, die einem bestimmen 
Programmier-Muster folgen. Gebiindelte Aufrufe von Ele- 
mentaroperationen enthalten i.A. triviale Muster von Pro- 
gram mlogik: nur bei Erfolg der ersten Operation wird die 
nachste aufgerufen, wobei Ergebnis-Parameter der ersten 
Operation an die zweite weitergegeben werden. Es kpmmen 
viele verschiedene Muster in Betracht. 

Die Idee besteht nun darin, die Implementierung hau- 
fig vorkommender Muster (siehe z.B. Abschnitt 3.3.8) 
von der Implementierung der Elementaroperationen zu se- 
parieren. Hierfur eignen sich dedizierte Bausteine pat- 
tern_*, die sich mit beliebigen anderen Bausteinen kom- 
binieren lassen. Dies bewirkt praktisch eine Schnittstellen- 
Erweiterung, die jedoch keine neue Funktionalitat einfiihrt, 
sondern lediglich der Bequemlichkeit und teilweise auch 
der Performanz- Verbesserung dient. Insbesondere bei Ver- 
wendung von RPC-Mechanismen in remote-Bausteinen 
sorgt die gebiindelte Ubertragung einer einzigen Operation 
liber ein Netzwerk fur die Einsparung von Nachrichten und 
Latenzzeit, wenn sie erst beim Server in Elementaropera- 
tionen aufgespalten und interpretiert, wird. Damit dies auch 
in groBeren Baustein-Hierarchien nutzbar wird, sollten re- 
lativ einfache Bausteine wie selector oder union, die 
fast gar nichts tun auBer Operationen mit geringen Modi- 
flkationen weiterzureichen, gebiindelte Muster als passend 
modifizierte Bundel an die nachste Instanz weiterreichen. 
Dies ist jedoch keine absolute Pfiicht 34 . 

Zur Umsetzung dieser Idee sollte ein Baustein in seinen 
Verhaltens-Attributen die Muster angeben, die er verwen- 
|den mochte. Die Instantiierungs- und Verdrahtungs-Logik 
(control und strategy^*, siehe Abschnitt 4.2) kann 
dann die passenden Muster-Bausteine automatisch an ge- 
eigneten Stellen einfugen und zwischenschalten, so dass die 
Verwendbarkeit der Muster auf jeden Fall sichergestellt ist, 
ohne sich darum sorgen zu mussen. Falls der untergeord- 
nete Baustein in seinen Kompetenz-Attributen angibt, mit 
einem bestimmten Muster umgehen zu konnen, wird die- 
ser Zwischenschritt ggf. ausgelassen. In gunstigen Fallen 
ergibt sich dadurch eine Kette von bundelungsfahigen Ver- 
drahtungen, die sich auch uber Speicher-Hierarchien hin- 
weg erstreckt und so die Performanz deutlich verbessert. 

33 In neuerer Zeit haben Performanz-Fragen ein erhohtes Interesse in der 
Literatur gefunden. Trotz des Bemiihens urn Vergleichbarkeit verschiede- 
ner Architekturen und Vorschlage ist diese nicht immer gegeben; das Stich- 
wort des Vergleiches zwischen Apfeln und Birnen findet sich nicht nur in 
[Lie95b]. 

34 Missachtung kann jedoch teilweise erhebliche EinbuBen bei der Per- 
formanz nach sich Ziehen. Wenn es dagegen auf schnelle Implementierung 
neuer Funktionalitat ankommt. erm6glicht das Weglassen von Bundeln so- 
genanntes ..rapid prototyping 1 *. 
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2.8.2 Zero-Copy-Architektur 

Fruhere IOSchnittstellen wie die von Unix [RT74] oder 
[Che87] besaBen eine implizite Kopier-Semantik. Neuere 
Entwicklungen wie [BS96, PDZ99, PDZOO] vermeiden das 
Herstellen von Kopien in moglichst vielen Situationen. Es 
ist bekannt, dass dies dramatischen Einfluss auf die Perfor- 
manz haben kann. 

Die hier vorgestellte Architektur definiert daher die 
IO-Funktionalitiat der Nest-Schnittstelle mit Hilfe von 
Referenz-Semantik; die Ubergabe von physischem Spei- 
cher uber Schnittstellen hinweg erfordert dies ohnehin. Da- 
mit ist kopierfreie Ubergabe von Daten uber beliebig groBe 
Baustein-Hierarchien hinweg moglich. Falls in besonderen 
Fallen eine Kopier-Semantik gewunscht wird oder notwen- 
dig ist, kann sie leicht als interne Strategie durch einen Bau- 
stein implementiert werden. 

2.8.3 Das Background-IO-Konzept 

Durchsatz-begrenzendeFtoc/i€/i/z^/^ treten oft in komple- 
xen Netzwerken von Baustein-Verdrahtungen oder in ver- 
teilten Systemen auf. Wenn ein Falschenhals auf physika- 
lischen Bedtngungen beruht (z.B. bei Festplatten-IO), laBt 
er sich prinzipell nicht entfernen (auBer durch Kauf schnel- 
lerer und teurerer Hardware). Man kann jedoch Methoden 
entwicklen, urn mit derartigen Flaschenhalsen besser leben 
zu konnen, d.h. zu versuchen, „das beste draus zu machen". 

IO-Prioritaten diesen diesem Zweck. Mittels IO- 
Prioritaten lassen sich wichtige von unwichtigen IO- 
Operationen trennen. Ich schlage die Verwendung folgen- 
der IO-Prioritasstufen vor: 

prio_background Der IO-Auftrag kann irgendwann 
ausgefiihrt werden, beispielsweise wenn an- 
sonsten ungenutzte Ubertragungs-Bandbreite 
frei geworden ist. Die Wartezeit bis zur Aus- 
fuhrung darf beliebig lang sein; es werden 
keinerlei Fairness-Bedingungen garantiert oder 
erwartet. 

prio_normal Def IO-Auftrag muss prinzipiell gleich- 
berechtigt zu anderen Auftragen bearbeitet 
werden, die ebenfalls prio__normal haben. 
Der Auftrag muss nach endlicher Zeit erle- 
digt sein (kein Verhungern). Permutatlonen 
der Abarbeitungs-Reihenfolge sind im Rah- 
men dieser Bedingungen erlaubt. 

prio_urgent Der IO-Auftrag ist anderen vorzuziehen. 

Die groBere Wichtigkeit hat eine logische Be- 
grundung (beispielsweise Sicherung wichtiger 
Meta-Daten). 

Die Idee besteht darin, bei Verstopfung eines IO- 
Flaschenhalses Auftrage mit prio_background voll- 
kommen zu verdrangen. Bei geeigneter Realisierung lasst 
sich dies so gestalten, dass Hintergrund-Auftrage die nor- 
malen IO-Aktivitaten iiberhaupt nicht storen. 

Bei Festplatten kann man dies folgendermassen rea- 
lisieren: erst werden alle Auftrage mit prio_urgent 
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und prio_normal abgearbeitet Danach folgt eine spe- 
kulative Wartepause in der GroBenordnung von 10ms 
bis 100ms, nach deren Ablauf erst mit dem Abarbei- 
ten der Hintergrund-Operationen begonnen wird. Falls 
wahrend dieser Wartepause erneute Operationen mit 
prio_urgent oder prio_normal eintreffen, werden 
keine Hintergrund-Operationen gestartet, sondern die hoher 
priorisierten sofort vorgezogen; danach beginnt die Warte- 
pause von vorn. Der Sinn dieser Wartepause besteht dar- 
in, den mechanisch bewegten Schreib-Lesekopf nicht zu 
verstellen, falls eine Anwendung ihre IO-Anforderungen 
zwar in Gruppen (Bursts) stellt, zwischen den Anforde- 
rungen aber sehr kurze Lucken (z.B. wegen kurzer Re- 
chenzyklen) einlegt. Ohne die Wartepause konnte der me- 
chanische Arm der Festplatte wahrend der sehr kleinen 
Lucke zwischen normal-priorisierten Burst-Operationen 
(wenige Mikro- oder Nanosekunden) auf die Position der 
Hintergrund-Operation verstellt werden, was bei heutigen 
Festplatten im Mittel etwa 5ms bis 10ms dauert, und her- 
nach wieder auf die Position des Burst-Prozesses zuriick- 

■dlt werden. Da das mechanische Verstellen urn meh- 
jfrpssenordnungen langsamer geht als das sequentielle 
•on Burst-Datenblocken, wQrde dieses andauernde 
^nische Hin-und-Herstellen zu einem Trashing-Effekt 
mit einem Zusammenbruch des Daten-Durchsatzes fuhren. 
Die Wartepause lost dieses Problem durch eine Spekulati- 
on auf das Eintreffen weiterer wichtiger Operationen. Wenn 
diese Spekulation nach einer relative langen Zeit von ei- 
nigen Vielfachen der mittleren Zugriffszeit der Festplatte 
sich nicht erfullt hat, dann ist es wegen der bekannten em- 
pirisch beobachteten zeitlichen Ungleichverteilung der IO- 
Anforderungen sehr unwahrscheinlich, dass ausgerechnet 
dann weitere IO-Operationen mit normaler Prioritat eintref- 
fen, wahrend der Kopf fur die Hintergrund-Auftrage ver- 
stellt wird. Falls dieser Fall trotzdem einmal eintreten sollte, 
dann verschlechterter den ohnehin sehr geringen Durchsatz 
der normal-priorisierten Auftrage nicht mehr wesentlich. 

Wenn man das Konzept eines den Normalbetrieb prak- 
tisch nicht storenden Hintergrund-IO-Betriebes in die Nest- 
Sc^^telle aufnimmt, ergeben sich neuartige Realisierun- 
mt Mas Problem der Persistenz Uber SpeicherlOcken 
h ^B^ So scnadet es beispielsweise in einem Buffer- 
Cache uberhaupt nicht, wenn man jegliche geanderten Puf- 
fer sofort nach Bekanntwerden der Anderung (Wechsel in 
den „dirty"-Zustand des Puffers) einen IO-Auftrag zum 
Abspeichern mit Hi ntergrund- Priori tat generiert. Falls der 
Hintergrund-Auftrag sehr Iange nicht ausgefiihrt wird, dann 
entsteht der gleiche Effekt wie beim konventionellen Puf- 
fern ohne IO-Auftrag. Werden Hintergrund-Auftrage je- 
doch auf „heissen" (d.h. oft zugegriffenen) Seiten ausge- 
fiihrt, dann fuhrt dies in der Summe zwar zu einer hoheren 
Belastiing des IO-Kanals mit Auftragen, diese fallen jedoch 
nur die ansonsten ungenutzte Rest-Bandbreite des Kanals, 
die ansonsten „verschwendet" worden ware. 

Im Endeffekt entsteht dadurch eine zeitnahe Sicherung 
transienten Speichers auf persistente Hintergrund-Medien, 
die sich automatisch an die aktuell verfugbare Bandbrei- 
te adaptiert. Bei hoher verfugbarer Bandbreite werden spe- 
kulative Sicherungs-Vorgange ausgefuhrt, die zu einer bes- 
seren Sicherheit gegen unvorhergesehene Ereignisse wie 
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Stromausfall fuhren. 

Die Hintergrund-Prioritat lasst sich weiterhin auch zum 
spekulativen Vor-Laden von Caches etc. nutzen. Spe- 
kulatives Ladevorgange konnen wegen der Hintergrund- 
Prioritat jederzeit von wichtigeren Vordergrund-Aktivitaten 
verdrangt werden. Die Realisierung solcher Preloading- 
Strategien kann beispielsweise durch zwischen geschalte- 
te Verhaltens-Beobachter-Bausteine erfolgen, die das IO- 
Verhalten einer Anwendung beobachten und analysieren 
und daraus Schlusse iiber das erwartete zukunftige Verhal- 
ten der Anwendung Ziehen. 

In Abschnitt 3.3.1 wird naher beschrieben, wie sich die 
IO-Prioritat bereits erteilter Auftrage nachtraglich erhohen 
lasst. Diese dynamische Anderungsmoglichkeit ist wichtig, 
da richtig spekulierte Anforderungen jederzeit zu „echten" 
Anforderungen einer Anwendung werden konnen. 
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Nester 



Die Abstraktion des Nestes stellt ein konkretes Speichermo- 
dell dar. Betriebssystem-Konstrukteure sind traditionell ge- 
wohnt, dass ihnen die Hardware eines Rechners oder eines 
Rechner-Typs ein bestimmtes Speichermodell vorschreibt 
oder zumindest in relativ engen Grenzen sehr nahe legt. 
Diesem Zwang versuche ich an einigen Stellen so zu ent- 
kommen, dass dadurch keine grundlegende Verschlechte- 

• rung der Performanz-Eigenschaften der Hardware ausgeldst 
wird. 
Eine Nest~Instanz ist ein logischer Adressraum, der von 
der Adresse 0 bis zu einer MaximalgroBe (mit mindestens 
64Bit l ) laufen kann. Mit logischen Adressen darf Adress- 
Arithmetik getrieben werden; es werden Bytes 2 adressiert. 

Ein Nest dient vor allem zur Abbildung von logischen 
Byte-Adressen auf physische Byte-Adressen von Daten- 
blocken. Damit soil u.a. das bekannte Konzept eines virtu- 
ellen Benutzer-Adressraums nachgebildet werden; dies ist 
jedoch prinzipiell unabhangig davon, ob MMU-Hardware 
in einem Rechner vorhanden ist oder nicht. Ein physischer 
Datenblock hat eine begrenzte Lange, innerhalb deren er 
sich durch Maschinenbefehle des Prozessors ansprechen 
lafit und innerhalb deren Adress-Arithmetik auf Basis von 
physischen Byte-Adressen getrieben werden darf. 

3.1 Arten von Nestern 

^^^^Es wird zwischen statischem und dynamischem Nest un- 
«ffyt erschieden : wahrend ein statisches Nest sich ahnlich wie 
^^^ein Unix-Device verhalt und auch nur im Zusammenhang 
mit Peripheriegeraten o.a. vorkommen sollte, basiert das ge- 
samte restliche System auf dynamischen Nestern. 

Ein dynamisches Nest kann im Unterschied zu einem 
konventionellen File abfragbare und veranderbare Locher 
im Definitionsbereich der partiellen Abbildung von logi- 
schen Adressen auf physische Adressen von Datenblocken 

l Noch groBere logische Adressraume, etwa mit 128 Bit oder mehr, 
haben durchaus praktische Anwendungen: das bekannte Segmentierungs- 
Modell (vgl. Multics [Org72] oder die Speichermodelle von Intel- 
Prozessoren) 13Bt sich durch einen linearen logischen Adressraum darstel- 
len, indem man ein (Segmentselektor.Offset)-Paar bildet, das insgesamt 
als logische Adresse eines (lochrigen) linearen Adressraums interpretiert 
wird. Wenn der Segmentselektor beispielsweise 64 Bit und der Offset 
ebenfalls 64 Bit umfasst, dann reicht ein logischer Adressraum von 128 
Bit fiir eine iiquivalente Darstellung des Segmentierungs-Modells durch 
den linearen Adressraum (vgl. auch das Thunk-Modell von Microsoft beim 
Obergang vom l6Bit-MSDOS-SpeichermodelI auf 32 Bit). 

2 In friiheren Zeiten war der Begriff Byte mehrdeutig, da er auch ande- 
re Bitfolgen als das Oktett bezeichnen konnte. Der Begriff ist inzwischen 
standardisiert und bezeichnet genau 8 Bit. 




enthalten, ahnlich wie ein Sparse File unter Unix (vgl. 
auch [Fot61, Lie95a]), jedoch wird diese Eigenschaft vom 
gesamten Betriebssystem auf alien Ebenen auBer Low- 
Level-Geratetreibern unterstutzt und auch intensiv genutzt. 
Als neuartige Elementaroperation kommt die transparen- 
te Verschiebung von logischen Adressbereichen hinzu. Ei- 
ne Verschiebung bewirkt, dass ein Teil des Definitionsbe- 
reiches der partiellen Abbildung von logischen Adressen 
auf Adressen von physischen Datenblocken so verschoben 
wird, dass dieselben Datenblocke anschlieBend unter einem 
Adress-Offset (im Vergleich zu den vorigen Adressen) im 
logischen Adressbereich erreichbar sind. Im Allgemeinen 
konnen durch Verschiebe-Operationen Locher im Definiti- 
onsbereich entstehen und/oder geschlossen werden, even- 
tual konnen am Ziel der Verschiebung auch Datenblocke 
„verloren gehen", d.h. sie werden nicht mehr vom Nest 
adressiert (konnen aber i.a. noch solange weiter existieren, 
solange noch dy namische Referenzen darauf bestehen). 

In konventioneller Terminologie bedeutet eine Verschie- 
beoperation, dass je nach Vorzeichen des Verschiebe- 
Offsets und Lange des verschobenen Bereichs eine Insert- 
oder Delete- oder Move-Operation in einer Datei, in ei- 
ner Datenbank, oder allgemein gesprochen in einem Nest 
durchgefuhrt wird. Ich verwende daher nur noch die Begrif- 
fe Nest und Verschiebe-Operation, urn diese Sachverhalte 
zu charakterisieren. 

Wichtig an der Verschiebe-Operation ist, dass sie trans- 
parent erfolgt. Damit ist £emeint, dass nur diejenigen Teile 
des Gesamtsystems von einer Verschiebung Kenntnis erhal- 
ten, die unbedingt davon betroffen sind; fur die anderen Tei- 
le ergeben sich durch die Verschiebung keine AnderurTgen. 

Hierzu ein Beispiel (siehe auch Abschnitt 4.1.4): aus 
dem oberen Ende eines Original-Nestes sei ein Teil-Nest 
ausgeschnitten worden. Die Ausschneide-Operation be- 
wirkt, dass die zugrunde liegenden Datenblocke sowohl im 
Original-Nest als auch im ausgeschnittenen Teil-Nest er- 
scheinen, dort jedoch unter neuen Adressen (im Regelfall 
bei 0 oder einer anderen festen Adresse beginnend). Nun 
finde eine Verschiebung im Original-Nest statt, die das ge- 
samte ausgeschnittene Teil-Nest mit umfasse, der gesam- 
te Ausschnitt also mit- verschoben werde. Transparenz be- 
deutet in diesem Beispiel, dass sich an den Adressen des 
ausgeschnittenen Teil-Nestes nichts andert. Benutzer des 
Teil-Nestes merken gar nichts davon, dass ihr Gastgeber- 
Adressraum „hinter ihrem Rucken" verschoben wurde. 
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3.2 Zugriffs-Modelle 




Auf einer Nest-Instanz Iassen sich Operationen ausfiih- 
ren, darunter elementare Grundoperationen. Operations- 
Aufrufe diirfen grundsatzlich parallel durch Aufrufer- 
Instanzen (wer auch immer das sein mag) bzw. asynchron 
an eine Bearbeiter-lnstanz (i.d.R. die Implementierung der 
Nest-Operationen) erfolgen. Die Bearbeiter-lnstanz bewirkt 
fur alle Operations-Aufrufe jeweils zugehorige Operations- 
Ausfuhrungen, deren ausgelosten Effekte die Ausfuhrung 
anderer Operationen beeinflussen konnen. Die Beeinfius- 
sung wird durch zwei grundlegende Modelle beschrieben: 

linearize_global Durch Operations- Ausfuhrung 
entsteht eine sequentielle Folge von Nest- 
Zustanden auf derselben Nest-Instanz. 
Es ist Aufgabe einer Implementierung 
von Nest-Operationen, fur die Einhaltung 
dieser sogenannten globalen Operations- 
Linearisierungs-EigenschafP (zur Grundidee 
vgl. [HW90] 4 ) zu sorgen. Verschiedene Nest- 
Instanzen sind grundsatzlich voneinander 
unabhangig, soweit nicht durch Bausteine 
Abhangigkeiten eingefuhrt werden. 

linearize_local Fur alle Operations-Aufrufe, die 
sich auf eine gegenseitig uberschneidendeTeil-. 
menge der logischen Adressen beziehen, wird 
eine sequentielle Folge von Zustanden definiert 
bzw. hergestellt; Operations-Ausfuhrungen auf 
verschiedenen logischen Adressbereichen ste- 
hen nicht notwendigerweise in einer Ord- 
nungsrelation zueinander (auch * Kommutier- 
barkeit 5 genannt). Damit wird LA. nur ei- 
ne Halbordnung zwischen den Operations- 
Ausfuhrungen auf derselben Nest-Instanz ga- 

3 Zum besseren Verstandnis kann man hilfsweise den Begriff der ..Folge 
von Operations-Aufrufen" einfiihren. Dann ist die Folge der Operations- 
Ausfuhrungen eine Permutation der Folge der Operations-Aufrufe, die fol- 
S e Q5te^ ere Bedingung erfullt: wenn man die beiden Folgen zu einer 
^|en Folge vereinigt, dann liegt jeder urspriingliche Operations- 
■ seiner zugehorigen Operations-Ausftihrung. Dieses Model! 
*»-^ nur a,s Hi,fskonslruk t ^uni besseren Verstandnis zu verwen- 
den!TeaIiter braucht man den Begriff der Folge von Operations-Aufrufen 
nicht einzufDhren, sondern es geniigt, von Operations-Aufrufen schlecht- 
hin zu sprechen, ohne dass diese in eine Folge gebracht werden mUssen. 
Der Grund hierfOr ist nicht, weil das Herstellen dieser Folge insbesonde- 
re in verteilten Systemen gewisse bekannte Schwierigkeiten macht (vgl. 
[AW94]), sondern weil man es zur Beschreibung der Semantik eines rein 
asynchronen Modells nicht benatigt. 

4 Im Gegensatz zum Konsistenzmodell der Linearisierbarkeit wird hier 
nicht eine spezielle Speicher-Semantik unterstellt, denen die Lese- und 
Schreiboperationen unbedingt gehorchen mussen. Weiter unten werden 
beispielsweise Lese-Operationen behandelt, die ausdriicklick die Auslie- 
ferung veralteter Versionen zulassen und daher im konventionellen Modeil 
der Linearisierbarkeit nicht enthalten sind. 

5 \m AHgemeinen ist die Disjunktheit der betroffenen Adressberei- 
che fiirdie Kommutation von Operations-Ausfuhrungen hinreichend, aber 
nicht notwendig. Sogenannte ..semantische Modelle" versuchen, die Aus- 
wirkungen normalerweise nicht kommutierbarer Operationen nachtraglich 
so zu interpretieren oder zu korrigieren, dass im Sinne irgendwelcher se- 
mantischer Anforderungen oder Bedingungen ein ..korrektes" Ergebnis 
herauskommt. Ein derartiger Korrektheitsbegriff muB nicht notwendiger- 
weise in alien moglichen AusfUhrungsfolgen den geleichen Endzustand er- 
reichen. In Abgrenzung zum KommutierbarkeiLs-Begriff mOchte ich dies 
Quasi- Kammutierbarkeit nennen. 
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rantiert (lokale Linearis ie rung 6 ). 

Giobale und lokale Linearisierung unterscheiden sich dem- 
nach nur in der Granularitat, mit der die Zustande bezeich- 
net werden; weitere Modelle werden in Kapitel 7 behandelt. 
Nur wenn lokal linerarisierte Operationen mit unterschied- 
lich groBen Adressbereichen auftreten, bei denen ein gro- 
Berer Adressbereich mehrere kleinere uberlappt, entstehen 
zwangslauflg halbordnungsartige Querbezuge zwischen an- 
sonsten unabhangigen Strangen von „Objekt"-Zustanden. 
Eine weitere Verfeinerung der Semantik von Nestern mit- 
tels Zusatzen wie z.B. Bausteine zur Implementierung ver- 
schiedener Arten von Serialisierbarkeit [Vid87] ist moglich 
und gehort zu den Strategies die mittels Bausteinen imple- 
mentiert werden konnen. Das Mbdell der lokalen Lineari- 
sierung ist ziemlich allgemein gehalten, urn verschiedene 
Konsistenz- oder Korrektheitsbegriffe als Spezialisierung 
ableiten zu konnen. 

Die Forderung nach (irgend)einer sequentiellen Folge 
von Nest- oder Adressbereichs-Zustanden (unabhangig von 
der Granularitat) laBt sich durch eine operational Semantik 
beschreiben. Diese legt nur fest, welche Operation welche 
Effekte auf einem Nest bzw. Adressbereich bewirkt, d.h. 
wie aus einem Zustand vi ein Zustand vj wird. Die Zustan- 
de Vi und vj werden auch als Versionen bezeichnet. Eine 
Operations-Ausftihrung impliziert zwischen den Versionen 
Vi und Vj die Relation der direkten funktionalen Abhangig- 
keiu Im AHgemeinen gilt j > z, d.h. die direkte funktionale 
Abhangigkeit ist eine Halbordnung: 




Die (oft wOnschenswerte) Eigenschaft der Determinant ist 
dann gegeben, wenn stets j = i + 1 gilt, d.h. die funktionale 
Abhangigkeit stellt eine Totalordnung dar: 



vO vl * v2 v3 



vn 



Die Folge der (globalen oder lokalen) Operations- 
Ausfuhrungen hangt per Konvention mit der Folge der 
Nest-Zustande in einer 1 : 1-Beziehung zusammen (d.h. jede 
Operation bewirkt genau eine Version des Nest-Zustands, 
die ggf. gleich zu einer fruheren Version ausfallen kann), 
auch wenn die Determinanz nicht gegeben sein sollte. 

Ein Zustand Vi einer Nest-Instanz besteht aus einer 
Adressabbildungs-Funktion a u die logische Adressen auf 

6 Der Begriff lokal bezieht sich hierbei auf eine Eigenschaft des Ne- 
stes, namlich seinen Adressbereich, und nicht auf eine bestimmte physi- 
sche Verteilung auf Rechnerknoten oder dergleichen. 

'Dieser Begriff soil zur Unterscheidung von den Begriffen Determi- 
niertheit und Determinismus dienen. Ich verwende den Begriff Nichtde- 
terminismus nicht, da sein Gegenteil, der Determinismus, in einem asyn- 
chronen Modeil nicht auftritt (bzw. nur als Spezialfall auftritt). Determi- 
niertheit ist auch nicht gegeben. weil i.a. die Reihenfolge der Ausfiihrung 
mehrerer paralleler Operationen nicht fest liegt. Determinanz ist ein Be- 
griff, der eine Zwischenstufe zwischen Determinismus und Nichtdetermi- 
nismus ausdrUcken soil: es entsteht zwar eine „deterministische M Folge der 
voneinander funktional abhangigen Zustande, doch diese Entstehung ge- 
schieht auf nichtdeterministische Weise aus Operations-Aufrufen, filr die 
keine Ordnung voraus gesetzt wird. 
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physische Adressen abbildet, und einer Datenabbildungs- 
Fuiiktion a\, die physische Adressen auf Bytes abbildet. Wir 
schreiben vi = (a»,di) und bringen damit zum Ausdruck, 
dass die Komposition der beiden Funktionen a* und d* den 
Zustand Vi vollstandig charakterisiert. Die Operationen las- 
sen sich in fojgende Ope rations- A rten einteilen: 

4. 

invariant Eine invariante Operation andert nichts am Zu- 
stand des Nestes, d.h. es gilt Vj = Vi. 

adressmodifizierend Es gilt dj = a\ und aj ^ a*. Eine 
adressmodifizierende Operation bewirkt, dass 
immer noch die gleichen Inhalte (Werte) physi- 
scher Datenblocke in der Nest-Instanz vorhan- 
den sind, diese jedoch teilweise unter neuen lo- 
gischen Adressen erreichbarsind. Adressmodi- 
fizierende Operationen setzen ein dynamisches 
Nest voraus. 

datenmodifizierend Es gilt aj = ai und dj ^ a\. Ei- 
ne datenmodiflzierende Operation ersetzt den 
Inhalt physischer Datenblocke durch einen 
anderen Inhalt in einem zusammenhangen- 
den Bereich des logischen Adressraums, der 
Modifikations-Bereich genannt wird; ausser- 
halb des Modifikations-Bereiches ist der Effekt 
der Operation invariant. Datenmodiflzierende 
Operationen konnen sowohl auf statische als 
auch auf dynamische Nester ausgefuhrt wer- 
den. 

Was mit den Zustanden ge*chieht, bzw. wofiir sie benutzt 
werden, ist eine eigenstandige Frage, die sich auf verschie- 
dene Weisen beantworten laBt. Ich prppagierefolgende Mo- 
deller 

singleuser Es ist nur eine einzige Aufrufer-Instanz 
vorhanden, die Operations-Aufrufe auf der 
Nest-Instanz ausfuhren kann. Im allgemeinen 
kann diese Aufrufer-Instanz dennoch mehre- 
re parallele (asynchrone) Operations-Aufrufe 
tatigen. Die Nest-Instanz sichert dem Aufru- 
fer die Determinanz zu. Der Aufrufer hat nur 
Zugriff auf die jeweils letzte Version v n der 
Zustande der Nest-Instanz, bzw. Anderungen 
erfolgen nur dort (Single-Copy-Eigenschaft). 
Bei mehreren parallelen Operations-Aufrufen 
durch denselben Aufrufer wird keine konkrete 
Reihenfolge der Operations- Ausfiihrungen zu- 
gesichert. Falls der Aufrufer jedoch stets nur 
einen einzigen Operations- Aufruf in Auftrag 
gibt, wird ihm eine konkrete Reihenfolge zu- 
gesichert. 

multiuser Es durfen mehrere Aufrufer-Instanzen vor- 
handen sein. Diesen wird die Eigenschaft 
der Determinanz zugesichert. Im Vergleich 
zum Singleuser-Modell erhSlt eine einzelne 
Aufrufer-Instanz trotz Beauftragung mit einem 
einzigen Operations-Aufruf nicht mehr die Zu- 
sicherung, in welcher Reihenfolge die Ausfuh- 
rung gegenuber den Auftragen anderer Instan- 
zen geschieht. 
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multiversion Dieses Modell wird in Kapitel 7 be- 
handelt und zerfallt in mehrere Untermodelle. 
Es durfen mehrere Aufrufer-Instanzen vorhan- 
den sein, Diese haben im allgemeinsten Un- 
termodell potentiellen Zugriff auf alle Adress- 
Versionen o< und alle Daten-Versionen dj ei- 
ner Nest-Instanz, womit ein Zugriff auf be- 
liebige Pseudo-Zustdnde v' {j = (a^d,) mog- 
lich ist, bei denen i = j nicht unbedingt gel- 
ten muB (was jedoch in einigen Untermodellen 
eventuell gefordert werden kann). Damit wird 
nur noch die Zusicherung gegeben, dass die 
Operations-Ausfuhrung auf irgendeiner giilti- 
gen (also nicht auf einer undeflnierten) Version 
der Adress- und Datenabbildung stattfindet, die 
jedoch auch alter sein kann. 

Die Modelle singleuser und multiuser erfiillen per 
Konstruktion die Eigenschaft der Determinanz, haben also 
die Semantik von Halbleiter- oder Plattenspeichern, bei de- 
nen eine Schreiboperation die vorherige Version ersetzt und 
nicht mehr zuganglich macht. Im Folgenden werden wir uns 
auf diese beiden Modelle beschranken und multiversi- 
on in Kapitel 7 gesondert betrachten. 

Die Eigenschaft der Korrektheit wird durch die hier 
beschriebenen Nest-Modelle nicht betrachtet 8 ; die damit 
verbundenen Probleme sind auf anderer Ebene zu losen. 
Dies ermoglicht konkreten Baustein-Implementierungen, 
verschiedene Modelle von Korrektheit auf Basis der°ail- 
gemeineren Abstraktion Nest zu erfiillen. Jede Aufrufer- 
Instanz hat daher die Verpflichtung, selbst 9 fur die Erf ul lung 
weiterer von ihr selbst gegebenen Zusicherungen, insbeson* 
dere die Korrektheit (im von ihr selbst deflnierten Sinne) zu 
sorgen. Die Abstraktion der Nester stellt jedoch dafiir eine 
(hoffentlich bequeme) Infrastruktur zur Verfugung. 

Eine Nest-Implementierung braucht nicht unbedingt alle 
drei Modelle zu unterstutzen. Welche Modelle im Einzel- 
fall unterstiitzt werden, gehort zu den Kompetenzen (vgl. 
Abschnitt 2.5) der Nest-Implementierung. Wie bereits ge- 
sagt, miissen die Kompetenzen der Nest-Implementierung 
zum Verhalten einer Aufrufer-Instanz kompatibel sein. 

Die Tabelle 3.1 zeigt die. moglichen Kompatibilita- 
ten. Die Tripel bedeuten hierbei, wie viele verschiede- 
ne Aufrufer-Instanzen mit Verhalten singleuser, mul- 
tiuser und multiversion jeweils an einer Konfi- 
guration mit einer Nest-Implementierung der betreffenden 
Kompetenz teilnehmen durfen. Wahrend sich singleu- 
ser mit keinem anderen Aufrufer- Verhalten vertragt, sind 
multi* beliebig untereinander mischbar, sofern die Nest- 
Implementierung von ihren Kompetenzen her mitspielen 
kann. 



Die einzeJnen Elementaroperationen mOssen nattirlich trotzclem die 
..Korrektheit" oder cesser die „Validitat" auf ihrer jeweiligen Abstrakti- 
onsebene bzw. Zugriflfs-Granularitat erfiillen. 

IJ Die Abstraktion der Nester gibt jedenfalls keine Zusicherungen ttber 
..Korrektheit", sondern hochstens Uber die (Nicht-)Kommutierbarkeii von 
Elementaroperationen. Den Aufrufern wird Uberiassen. welche Semantik 
sie irnplementieren wollen; dabei dUrFen und sollen sie sich jedoch auf die 
Zusicherungen der Nest-Implementierung abstUtzen. 
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Kompetenz 



singleuser 



multiuser 
inul t i ver s i on 



singleuser 



Verhalten 



(1,0,0) 



(1,0,0) 
(1,0,0) 



multiuser 



(0,n,0) 



(Q,n,m)' 



multiversion 



Tabelle 3.1: Kompatibilitaten von Kompetenzen und Verhalten 



3.3 



Elementaroperationen auf stati- 
schen und dynamischen Nestern 

Der hier vorgestellte Satz von Elementaroperationen auf 
Nestern ist als Beispiel zu verstehen, wie man die Schnitt- 
stelle zu Nestern gestalten kann. Die Beschreibung ist in- 
formell und soil die Kernidee erklaren; es handelt sich nicht 
urn eme vollstandige Spezifikation aller Details. 

Der Entwurf von IO-Schnittstellen wird in der Pra- 
xis durch diverse Umstande verkompliziert, die nach mei- 
Mj^furhalten fur einen GroBteil der Implementierungs- 

m^^SK itat fealer Betriebss y steme mitverantwortlich sind. 
^P^Berucksichtigung dieser Umstande bereits in den 
Scntuttstellen und im gesamten System uber alle Ebe- 
nen hinweg™, sowie durch die Unterstutzung so genann- 
ter „fortgeschrittener IO-Konzepte" wie asychroner IO und 
Nonblocking-IO mittels universeller Generizitat laBt sich 
diese Komplexitat reduzieren 11 . Daher enthalt bereits die 
Schnittstelle fur statische Nester alle im System vorkom- 
menden IO-Konzepte. 

Ich habe versucht, im folgenden Entwurf auch die An- 
forderungen von Datenbanken so weit zu berucksichtigen 
dass hoffentlich die Grundfunktionalitat eines DatenbaW 
Systems abgedeckt werden kann 12 . 

Sperrmechanismen dienen dazu, die mdglichen Ausfuh- 
rungsfolgen von Operationen einzuschranken. Als Sperr- 
mechanismen sind bei statischen und dynamischen Nestern 
die elementaren Grundoperationen lock und unlock vor- 
gesehen, die die einzigen Sperrmechanismen sind, die im 
^^^^Betriebssystem benotigt werden 13 . 

Buffer-Caches wie beispielsweise [PDZ99] vereinheitlichen 
zwaroas Caching in einem System auf ahnliche Weise wie hier fiihren ie- 
doch ihre eigene Schnittstelle ein. Im Gegensatz dazu verlangt das Prinzio 
der universellen Generizitat (Abschnitt 2.1.4), dass die Nest-Schnittstelle 
nicht verandert wird, wenn Caching irgendwo eingefiihit oder nicht mehr 
benutzt wird. 

"i" ^Ji!?^ 1 * 611 EmwickIu "g erfolgreicher Betriebssystem-Kerne 
wie der UNIX-Farmlie wurden immer wieder so genannte „Balkone" an 
die vorhandenen Konzepte angebaut, urn mit geanderten und erweiterten 
Anforderungen Schritt halten zu konnen. Balkone widersprechen der For- 
derung nach moglichst geringer Redundanz eines Entwurfs. Die hier vor- 
geschlagenen Schnittstellen- Konzepte und Abstraktionen versuchen das 
Ideal von universeller Generizitat anzunahern, um auch zuktinftige unvor- 
hersehbare Anforderungen mit etwas GlUck ohne Balkone nachriisten zu 
konnen. 

"Falls fortgeschrittene Konzepte der Implementierung von Datenbank- 
Systemen [HR0I] nicht ausreichend beriicksichtigt sein sollten, dann hoffe 
ich, dass sich diese Mechanismen ebenfalls in die vorgestellte Architektur 
nut genngem Aufwand integrieren lassen. 

"Dies gilt auch fOr die bekannte Multiprozessor-Problematik (SMP) 
und I die b.sher durch Unterbrechungs-Sperren geldsten Synchronisations- 
probleme, die durch geeignet implementierte Elementaroperationen lock 

KnJJSmn? • Sb , ar Sind - SOfem man U-terbwchungen als vollwertige 
Kontrdllflilsse implementiert (vgl. [KE95]). 



Em statisches Nest laBt sich als Einschrankung eines 
dynamischen Nestes verstehen, bei dem die Verschiebe- 
Operation fehlt und keine Locher im Definitionsbereich 
vorkommen, sowie in den meisten Fallen (etwa bei 
Festplatten-Partitionen) keine dynamische Anderung der 
GroBe erfolgt. Allerdings wird diese abstrakte Sicht nicht 
vo Ikommen von der Realitat aktueller Peripheriegerate a e - 
teilt: die Granularitat von Datentransfers ist bei aktueller 
Peripherie auf Bl6cke fester Lange, etwa 5 12 Byte bei Fest- 
platten oder 2048 Byte bei CD-Laufwerken, begrenzt. Dar- 
uber hinaus diirfen Datentransfers nur an solchen Adressen 
stattfinden, die durch die Granularitat ohne Rest teilbar sind 
Diese Einschrankungen werden durch ein Attribut trans - 
fer_size modelliert, das jeder Nest-Instanz zugeordnet 
ist, und das jeder Verwender eines Nestes abfragen und bei 
semen IO-Auftragen berucksichtigen muss. 

Bei statischen und dynamischen Nestern sorgen die Ele- 
mentaroperation dafiir, dass die logischen Adressen (die 
relativ zurn jeweiligen Nest gelten) auf physische Adres- 
sen von transienten Datenblocken ubersetzt werden Die 
Zustandigkeit fur die Verwaltung der physischen Adressen 
kann unterschiedlich geregelt sein. Hierfur werden zwei Be- 
tnebsarten unterstUtzt, die prinzipiell auch gemischt nutzbar 
sind: logischer IO und physischer IO. 

Beim logischen IO geschiehtdie Verwaltung (Platzreser- 
vierung und -Freigabe) der transienten Datenblocke im phy- 
sischen Hauptspeicher durch die Operation get, wahrend 
beim physischen IO dafur der Aufrufer selbst verantwort- 
hch ist. Physischer IO sollte idealerweise nur auf den unte- 
ren Schichten von Geratetreibern benutzt werden, das rest- 
hche System benutzt normalerweise logischen IO Die Un- 
terschiede zwischen beiden Betriebsarten sind gerin» und 
werden lediglich durch eine unterschiedliche Parameter- 
Versorgung von get ausgedruckt. 

Die Elementaroperationen wickeln zusammen nicht nur 
samthchen asynchronen IO ab, sondern erlauben auch den 
transparenten Einsatz eines Buffer-Cache ohne Anderun- 
der Schnittstelle. Wie wir spater sehen werden, fiihren sie 
auch die Speicherverwaltungs-Funktionalitat des Systems 
durch, sogar diejenige des Paging von virtuellen Benutzer- 
Speicherseiten.Aus der folgenden Beschreibung des asyn- 
chronen IO-Modelles ergibt sich die Realisierung von syn- 
chronem IO und Nonblocking-IO auf triviale Weise, so dass 
ich mir deren Ausfuhrung sparen werde. 

Das foglende Bild enthalt eine Ubersicht iiber die Ele- 
mentarooperationen auf statischen Nestern: 
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Wie zu sehen ist, werden die Elementaroperationen im- 
mer paarweise mit einer entgegengesetzten oder aufheben- 
den Operation kombiniert. Verschiedene Arten von IO oder 
sonstige Zugriffs-Arten auf Nester ergeben sich durch ein 
Schichtenmodell, das hier kurz von innen nach auSen skiz- 
ziert werden soli: 

Im einfachsten Fall wird physischer IO durch die Opera- 
tion transfer betrieben. Die Funktionalitat synchrone- 
nen IOs entsteht durch anschlieBendes Warten auf die Be- 
endigung mittels wait. Bei asynchronem IO kann auch 
auf den Aufruf von wait verzichtet werden. Bei logi- 
schem IO wird die Abbildung von logischen auf physi- 
sche Adressen von der Operation get iibernommen. Durch 
den paarweisen Aufruf von put wird die Ressourcen- 
Verwaltung auf ahnliche Weise wie bei einem konventio- 
nellen Buffer-Cache gelost (interne Verwendung von Refe- 
renzzahlern). Damit ein Ausgang eines Bausteins mit meh- 
reren Eingangen anderer Bausteine parallel verdrahtet wer- 
den darf (multiuser-Kompetenz), wird der wechselsei- 
tige Ausschluss (vgl. [Lag78]) bei parallelem Zugriff durch 
|die Operationen lock und unlock bereit gestellt. Zur 
Nachbildung von Pipes u.a. sowie zur Speicherverwaltung 
existieren weitere Elementaroperationen get_address 
und put_address, mit denen das Problem der atomaren 
Reservierung von Adressbereichen insbesondere im Falle 
mehrerer paralleler Zugreifer lfisbar ist. 

3.3.1 transfer 

Diese Elementaroperation sorgt dafiir, dass eine 
Aktualisierungs-Operation in eine der beiden mfigli- 
chen Richtungen zwischen Iogischer Adresse im Nest 
und physischem Datenblock beauftragt wird (ohne auf die 
Ausfiihrung dieser Operation zu warten). Eine derartige 
Aktualisierungs-Operation wird synonym IO-Operation 
oder lO-Auftrag genannt; anstelle des Begriffs IO- 
Operations-Ausfuhrung wird synonym auch der Begriff 
Beendigung des IO-Auftrags verwendet. Verschiedene 
IO-Auftrage sind prinzipiell voneinander unabhangig. Die 
Schnittstelle sieht folgendermaBen aus: 



stop 



transfer(nest, mandate, log_addr, len, 

Phys_addr, direction, io_prio, 

depend) success 

Der Parameter direction kann einen der folgenden Wer- 
teannehmen: 

read Die Aktualisierung erfolgt von der logischen 
Adresse im Nest in Richtung zum physischen 
Datenblock. Nach erfolgreicher Beendigun° 
des IO-Auftrages wird zugesichert, dass sich 
die neueste Version an der physischen Adres- 
se befindet. 

Die Aktualisierung erfolgt in Richtung von der 
physischen Datenblock-Adresse an die logi- 
sche Adresse auf dem Hintergrund-Medium 
Mit Durchfiihrung des IO-Auftrages entsteht 
eine geanderte neueste Version des Nest- 
Zustandes. 

Ein eventuell bereits wartender IO-Auftrag 
wird wieder aus der Warteschlange der war- 
tenden Auftrage entfernt, sofern dies moglich 
ist; bei bereits in Ausfiihrung befindlichen IO- 
Auftragen ist dies im Regelfall nicht mehr 
moglich. Die Folge ist, dass die von den an- 
deren direct ion- Arten gegebenen Zusiche- 
rungen nicht mehr eihgehal ten werden miissen. 
Falls ein read-Auftrag abgebrochen wurde, 
steht anschlieUend max_version auf un- 
defined. 

Der IO-Auftrag erfolgt mit der Prioritatsangabe io_prio 
die in Abschnitt 2.8.3 ausfuhrlicher erklart wird Im Re- 
gelfall werden Auftrage mit einer hoheren IO-Prioritat 
vor solchen mit geringerer Prioritat ausgefuhrt; Ausnah- 
men sind moglich, wenn dadurch der Gesamtdurchsatz des 
IO-Systems gesteigert wird. Der Parameter depend er- 
laubt die Spezifikation einer Halbordnung zwischen 10- 
Auftragen, was insbesondere zur Implementierung absturz- 
sichereratomarer Operationen bzw. Transaktionen bendti-t 
wird. Es wird eine Liste derjenigen logischen Adressen an- 
gegeben, deren zugehSrige IO-Auftrage (sofern sie existie- 
ren) auf jeden Fall beendet sein miissen, bevor der aktuelle 
IO-Auftrag ausgefiihrt (physikaiisch gestartet) werden darf. 

Falls transfer auf einen bereits vorhandenen IO- 
Auftrag trifft, sollte ein doppelter Eintrag von gleichlau- 
tenden Auftragen vermieden werden; statt dessen wird le- 
dighch em intern zugeordneter Referenzzahler erhoht (die- 
ser muss erst ab mul tiuser-Kompetenz vorhanden sein). 
Dadurch wird eine Uberflutung des IO-Systems durch un- 
notige IO-Auftrage selbst bei massenhaftem Einsatz von 
Background-IO (vgl. Abschnitt 2.8.3) verhindert. Ggf. wird 
die IO-Prioritat eines bereits wartenden Auftrages auf das 
neue Niveau erhSht, so dass in Zukunft mit einer zugigeren 
Bearbeitung zu rechnen sein wird. 

Im boolschen Ergebnis-Parameter success wird zu- 
riickgemeldet, ob ein erfolgreiches Erzeugen des IO- 
Auftrages moglich war. 
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33.2 wait 

Diese Elementaroperation implementiert mittelfnstiges 
Warten. Die Schnittstelle sieht folgendermaBen aus: 

wait (nest, mandate, log_addr, len, 

pause, keep) -> 
( min_vers i on , max_ver s i on ) 

Falls der boolesche Parameter pause gesetzt wurde und 
(noch) ein IO-Auftrag existiert, der noch nicht ausgefuhrt 
(physikalisch beendet) wurde, wird auf die Beendigung ge- 
wartet Der boolesche Parameter keep iegt fest, ob der in- 
terne Referenzzahler eines vorhandenen Auftrages (selbst 
nach erfolgreicher Beendigung) belassen werden oder de- 
krementiert werden soli; beim Belassen ist eine Status- 
abfrage durch nachfolgende wait-Operationen derselben 
Aufrufer-Instanz weiterhin moglich. Durch entsprechende 
Kombinationen der pause- und keep-Parameter ist Pol- 
ling moglich. Auftrage, deren Referenzzahler zu 0 gewor- 
^■j^diirfen bzw sollen entfernt werden. 
M M Ergebnis-Parameter min.version und 
^^^sion melden die Aktualitat nach der fol- 
genaen Systematik: 

undefined Der Inhalt des Datenblocks an der zuriickge- 
lieferten physischen Adresse ist undefiniert° 

newes t Die Nest-Implementierung sichert zu, dass die 
neueste Version des Nest-Zustandes im Da- 
tenblock ausgeliefert wurde, die zum Zeit- 
punkt der Operations-Ausfuhrung giiltig war. 
Sofern keine Sperrmechanismen die Ausfuh- 
rung weiterer Operationen verhindern, wird 
nicht garantiert, dass in der Zwischenzeit zwi- 
schen der Operations-Ausfuhrung und der In- 
spektion durch die Aufrufer-Instanz keine wei- 
teren Operations-Ausfuhrungen stattgefunden 
haben, die den Nest-Zustand inzwischen ver- 
andert haben. 




Zwischen diesen Werten gilt die Relation undefi- 
ned < newest. Weiterhin gilt minevers ion < 
max_yersion. Der Wert von minevers ion bedeu- 
tet, dass sich die Nest-Implementierung dessen sicher ist, 
dass der Datenblock mindestens die angegebene Aktua- 
litat besitzt. Umgekehrt bedeutet max_version, dass 
die Nest-Implementierung sicher ist, dass die Versi- 
on den angegebenen Aktualitatsgrad nicht uberschreitet. 
Wenn die Nest-Implementierung beispielsweise uberhaupt 
nichts iiber die Aktualitat weiB, dann ist minevers ion 
~ undefined und max_version = newest. Nur 
wenn minjversion = max_version = newest 
gilt, ist der Datenblock aktuell. Aus min_version = 
max^version = undefined kann gefolgert werden, 
dass entweder kein IO-Auftrag (mehr) vorhanden ist, oder 
dass sein Effekt durch transfer im stop-Modus wie- 
der aufgehoben wurde, oder dass die trans f er-Operation 
technisch nicht erfolgreich war (Schreib- oder Lesefehler). 



3.33 get 

Ein Buffer-Cache verwaltet eine transiente interne Zuord- 
nung zwischen logischen und physischen Adressen Diese 
Zuordnung ist transient, d.h. sie gilt langstens fdr den Zeit- 
raum, in dem das Betriebssystem lauft, und kann wieder 
aufgelost werden, sobald keine dynamischen Referenzen 
mehr auf den physischen Datenblock bestehen. Trotzdem 
sollte die Zuordnung nach Moglichkeit langere Zeit beste- 
hen, als der Aufrufer unbedingt verlangt Ohne die Mog- 
lichkeit zur Aufbewahrung einer zeitlich langer dauernden 
Zuordnung zwischen logischen und physischen Adressen 
ware eine Caching- Funktionalitat nicht oder nur schlecht 
erfullbar. 

Die Elementaroperation get verwaltet daher eine transi- 
ente interne Zuordnung zwischen logischen und physischen 
Adressen. Die Schnittstelle umfasst folgende Parameter: 

get (nes t , mandate , log_addr , len, mode ) -> 
( Phys_addr , 1 en , minever s i on , max__vers i on ) 

Die ubergebenen Adressen miissen zur erfolgreichen 
Durchfuhrung durch trans fer_size teilbar sein, die 
Lange muss ebenfalls ein Vielfaches davon darstellen. Als 
Ergebnis wird die physische Adresse zuruckgeliefert, so- 
fern die Operation erfolgreich war, ansonsten eine NULL- 
Adresse. Die zuriickgelieferte Lange darf kurzer als die an- 
geforderte Lange sein (beispielsweise wenn das unterlie- 
gende IO-System keine Transfers mit der gewunschten Lan- 
ge am Stuck ausfuhren kann), sie muss aber durch trans - 
f er_size teilbar sein. 

Die Nest-Instanz sucht auf atomare Weise in ihren inter- 
nen Zuordnungs-Strukturen (z.B. schnelle Hash-Tabellen), 
ob bereits eine Zuordnung mit einem physischen Daten- 
block an der gewunschten logischen Adresse besteht. Falls 
ja, dann wird diese Adresse und die ggf. gekiirzte Lan- 
ge zuruckgeliefert. Falls noch keine Zuordnung besteht, 
wird Plate fur einen neuen zusammenhangenden Daten- 
block der Lange len allokiert, oder falls dies nicht mog- 
lich ist, ein moglichst groBer Datenblock bis zur Lange len 
(in Vielfachen von transf er_size). SchlieBIich wer- 
den die Adresse und Lange in die Zuordnungs-Strukturen 
emgetragen und zuruckgeliefert. Die Ergebnis-Parameter 
min__version und max_version sind wie bei wait 
deflniert. 

Physische Adressen von Datenblbcken stellen Aliase dar, 
die ab multiuser-Kompetenz von mehreren Aufrufern 
gemeinsam benutzt werden konnen. Es wird allerdings 
nicht garantiert 14 , dass verschiedene Aufrufer-Instanzen 
beim get an der gleichen logischen Adresse dieselbe 
physische Adresse zuruck erhalten 15 . Die Benutzung phy- 
sischer Adressen geschieht durch Maschinenbefehle, die 
von den Operationen der Nest-Implementierung unabhan- 
gig sind und wegen der Aliase prinzipiell zu einer Interfe- 
renz fiihren konnen, wenn nicht bestimmte Regeln einge- 
halten werden. Das Reglement sieht folgenderm alien aus: 

Jedem zuruckgelieferten physischen Datenblock ist ab 
multiuser-Kompetenz ein Referenzzahler zugeordnet, 

,4 Umgekehrt wird jedoch ebenfalls nicht garantiert, dass kein Alias ent- 
steht. 

,5 Dies ist in Verteilten Systemen im allgemeinen schlicht unm6glich. 
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der die Anzahl der auf ihn elBSEerenden Referenzen ver 
waltet. Ein Aufruf von get, der einen bereits vorhandenen 
Datenblock auffindet, inkrementiert diesen Referenzzahler. 
Falls ein neuer Datenblock allokiert wurde, dann steht der 
Referenzzahler regelmaBig auf 1 . Die logische Freigabe des 
physischen Datenblocks erfolgt durch die spater beschrie- 
bene Operation put, die den Referenzzahler wieder dekre- 
mentiert und daher immer paarweise zu get aufgerufen 
werden muss (gleiche Anzahl von Aufrufen). 

Der mandate-Parameter wird erst ab dem multiver- 
sion-Modell benotigt (siehe Kapitel 7). 

Der boolsche Parameter mode gibt an, ob der Aufrufer 
den Datenblock anschlieBend zu Schreibzwecken benutzen 
darf. Bei einigen Implementierungs-Paradigmen (vgl. Ab- 
schnitt 2.7) wird diese Information genutzt, urn VerstoBe 
gegen das Reglement zu erkennen und ggf. zu sanktionie- 
ren. Ab multiuser-Kompetenz wird durch einen weite- 
ren internen Referenzzahler gemerkt, wieviele Aufrufer den 
mode-Parameter gesetzt hatten. 

Falls mehrere Aufrufer den mode -Parameter gesetzt ha- 
ben, diirf en diese prinzipiell unabhangig voneinander eige- 
ne Anderungsoperationen auf dem physischen Datenblock 
ausfuhren, was zu Interferenzen fuhren kann 16 , wenn sie 
keine weiteren MaBnahmen ergreifen (z.B. durch Setzen 
von Locks 17 ). 

3.3.4 put 

Diese Operation dekrementiert den internen Referenzzah- 
ler, der jedem physischen Datenblock zugeordnet wird, auf 
atomare Weise. Die Schnittstelle Iautet: 

put ( nest , mandate , phys_ad&r , mode ) 

Falls der Referenzzahler durch diese Operation zu 0 wird, 
dann darf die ursprunglich durch get hergestellte Zuord- 
nung zwischen Iogischen und physischen Adressen wieder 
auf atomare Weise aufgelost werden und der Speicherplatz 
fur den Datenblock freigegeben werden. Dies soil jedoch 
moglichst nur bei Speichermangel geschehen. Nach dem 
letzten put haben Zugriffe auf die physische Adresse keine 
Bedeutung mehr fur die Aufrufer-Instanz. 

Falls irgendeine Instanz Zugriffe auf eine physische 
Adresse macht, die keine Bedeutung (mehr) fur sie hat, 
dann gilt dies als Fehler. Falls Fehler nicht abgefangen und 

^Interferenzen brauchen nicht generell zu entstehen; beispielsweise 
k6nnten externe Absprachen zwischen mehreren Schreibern bestehen, dass 
diese nur auf zueinander disjunkte Bereiche eines physischen Datenblocks 
iindernd zugreifen; ein typischer Anwendungsfall dafur ist z.B. ein Nach- 
richtenpuffer zur wechselseitigen Publikation von irgendwelchen Status- 
Informationen, die keinen Einfluss auf die Korrektheit haben, sondern 
z.B. zur Lastbalancierung genutzt werden. Die hier vorgestellte Archi- 
tektur mochte die Ldsung von Interferenz-Problemen durch Baustein- 
Implementierungen ermoRlichen und untersWtzen, aber nicht erzwingen, 
insbesondere denjenigen Implementierern keine Hemmschuhe in den Weg 
legen, die „wissen was sie tun" und die nicht filr Performanz-Overhead 
durch heherwertige Zusicherungen bezahlen mdchten. Im ubrigen las- 
sen sich heherwertige Zusicherungen jederzeit durch geeignete Bausteine 
nachriisten. 

,7 Interferenzen sind auch zwischen Nur-Lesern und einem Schrei- 
ber moglich. Die Nest-Implementierung Ubernimmt dafUr keine Ver- 
antwortung. In Abschnitt 3.3.5 wird beschrieben, wie Baustein- 
Implementierungen durch Locks fiir die Vermeidung von Interferenzen 
sorgen kSnnen. 
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verhmdert werden konnten (vgl. Abschnitt 2.7), dann kann 
sich als Folge daraus das gesamte System in einem unde- 
finierten Zustand befinden. Jegliche Instanzen haben daher 
die Pflicht, Fehler zu vermeiden. 

Durch den Parameter mode wird der interne Referenz- 
zahler fur die Anzahl der Schreiber verwaltet; Aufrufer ha- 
ben die Pflicht, diesen Parameter paarweise ubereinstim- 
mend zum mode-Parameter von get zu verwenden (Zu- 
widerhandlungen gelten als Fehler). 

33.5 lock und unlock 

Sperren bewirken, dass die moglichen Ausfuhrungs-Folgen 
von Operationen eingeschrankt werden. Die in un^se- 
rem Modell verwendeten Sperren wirken nicht nur g e - 
geniiber anderen Sperren, sondern auch gegenuber eini- 
gen anderen Elementaroperationen. Implementierungen 
von Bausteinen mussen fur die Realisierung irgendwelcher 
Korrektheits-Begriffegrundsatzlich selbst Sorge tragen, in- 
dem sie die moglichen Ausfuhrungsfolgen einer Nest- 
Instanz mit den zulassigen Ausfuhrungsfolgen ihres jewei- 
ligen Korrektheits-Begriffes vertrdglich machen. Dies bela- 
stet zwar die Baustein-Implementierungen mit der Pflicht, 
fiir diese Vertraglichkeit selbst zu sorgen, ermoglicht da- 
fur jedoch wesentlich flexiblere Korrektheits-Modelle. 1st 
eine Sperre erst einmal erfolgreich gesetzt worden, dann ga- 
rantiert die jeweils beauftragte Ausfuhrungs-Instanz (Nest- 
Implementierung) ihre Einhaltung gegenuber der Aufrufer- 
Instanz. 

Die hier vorgeschlagenen Sperren sollen neben der 
Grundfunktionalitat eines Betriebssystems auch wichtige 
Bereiche der Funktionalitat von Datenbanken und Transak- 
tionen (siehe z.B. [Dat95, EN95]) abdecken. Das hier vor- 
gestellte Modell ist als Vorschlag zu verstehen, der an man- 
chen Stellen verbessert werden kann (beispielsweise durch 
Einfuhrung intentionaler Locking- Arten). 

Die Elementaroperationen lock und unlock sperren 
bzw entsperren Bereiche des Iogischen Adressraunis gesen- 
iiber anderen Aufrufer-Instanzen der lock-Operation bzw. 
gegenuber anderen Mandats-Inhabern und gegenuber get; 
gehaltene Sperren gelten grundsatzlich als der aufrufenden 
Instanz bzw den in Abschnitt 2.7 beschriebenen Mandaten 
zugeordnet. Die gesperrten Bereiche miissen nicht notwen- 
digerweise im Definitionsbereich von dynamischen Nestern 
aktuell vorkommen („Ph an torn-Locks"); es findet also kei- 
ne Synchronisation auf Daten-Objekten statt, sondern ei- 
ne auf Iogischen Adressbereichen. lock-Operationen. die 
auf gegenseitig nicht uberlappenden Adressbereichen aus- 
gefuhrt werden, sind voneinander unabhangig und kommu- 
deren miteinander. Locks sind nicht rekursiv, sondern akku- 
mulierend innerhalb derselben Lock-Art. Es schadet nicht, 
wenn bereits erhaltene Lock-Bereiche von derselben In- 
stanz bzw unter dem gleichen Mandat nochmals angefor- 

l8 Bei Betriebssystem-Schnittstellen wird zwischen den Locking-Arten 
mandatory und advisory unterschieden. Die hier Verwendeten Locks ge- 
hdren zu keiner dieser beiden Arten. Es wird zwar ahnlich wie beim advi- 
sory locking niemand gezwungen, Locks zu verwenden; falls jedoch eine 
Aufrufer-Instanz einen Lock erhait, dann wird seine Einhaltung auch zu- 
gesichert, und zwar auch dann, wenn sich andere Instanzen „nicht an die 
Regeln halten". Im Gegensatz zum advisory locking wird eine Umgehung 
des Locks durch nicht-konformes Verhalten anderer Instanzen verhindert 
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dert werden, bewirkt aber auch nichts. Die Riickgabe mit- 
tels unlock braucht nicht den gleichen Adressbereich zu 
betrefFen als der vorherige lock. Damit ist es moglich, 
einen urspriinglich am Stuck liegenden gesperrten Bereich 
in kleinere Teilstucke mit zwischenliegenden freigegebe- 
nen Bereichen umzuwandeln. Umgekehrt darf ohne Scha- 
den ein grbBerer Bereich mittels unlock freigegeben wer- 
den als vorher mittels lock gesperrt wurde; falls man z.B. 
unlock mit dem gesamten Adressraum als Parameter auf- 
ruft, dann werden samtliche von der aufrufenden Instanz 
bzw dem Mandat gehaltenen Locks atomar auf einen Schlag 
freigegeben (strikter Zweiphasen-Commit). Die Parameter 
lauten: 

lock (nest, mandate, log_address , len, 

try_address, try__len, kind, action) -> 
(locked_address / locked_len) 
unlock (nest, mandate, log_address, len) 

Der Sperr-Adressbereich wird durch die Parameter 
log_address und len vorgegeben. Die Parame- 
ter try_address und try_len beschreiben einen 

Cs-Adressbereich, der einen Oberbereich des Sperr- 
ereichs darstellen muss. Falls der Versuchs- 
ereich echt groBer als der Sperrbereich ist, 
audit er von der Nest-Implementiening nur so- 
weit im Ergebnis-Sperrbereich locked_address und 
locked_len berucksichtigt zu werden, wie dies ohne 
zustitzliches Warten moglich ist. Nahere Erklarungen fur 
das damit mogliche spekulative Locking finden sich in Ab- 
schnitt 5.3. Der Ergebn is- Sperrbereich umfasst entweder 
mindestens den Sperr-Adressbereich (d.h. er liegt zwischen 
dem Sperr- und dem Versuchs-Bereich), oder er hat die Lan- 
ge 0. Im letzteren Fall war ein Setzen des Locks nicht mog- 
lich (s.u.). Durch den Parameter kind werde*n neben den 
bekannten Arten Read-Lock und Write-Lock 19 noch weiter 
verfeinerte Lock- Arten unterschieden. Er hat einen der fol- 
genden Werte: 



read Der Ergebn is-Sperrbereich ist anschlieBend 
vor Uberschreiben der ck-Komponente durch 
andere Aufrufer-Instanzen von lock und von 
get jeweils im write-Modus geschutzr 20 . 

Der Ergebnis-Sperrbereich ist anschlieBend 
zum Uberschreiben der di-Komponente fur 
den Aufrufer exklusiv reserviert. 

upgrade Wie write, jedoch wird ein bereits gesetzter 
Read-Lock zu einem Write-Lock atomar auf- 
gewertet (sofern es moglich ist); dieser Mo- 
dus wird bei einigen Transaktions-Modellen 
(insbesondere pessimistische Modelle) beno- 
tigt und sollte ausserhalb dieser Anwendung 
nur mit Vorsicht eingesetzt werden 21 . 



u Vgl. Semantik von File-Locking in neueren Unix-Abk6mmlingen 
[Vah96], die sowohl die Semantik von Mutex-Semaphoren als auch von 
read/write-Locks aus der Datenbank-Welt als Spezialfall umfasst 

20 1 m Fachgebiet der Datenbanken wird diese Eigenschaft als repeatable 
read bezeichnet. 

21 Falls mehrere Instanzen jeweils einen erfolgreichen Read-Lock auf 
derselben Version halten, dann kann nur eine einzige von ihnen diesen 
erfolgreich in einen Write-Lock umwandeln, da ansonsten der Schutz ge- 
gen Modifikation durch andere Instanzen (repeatable read) verloren ge- 



fix 



reorg 
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Der Ergebnis-Sperrbereich ist anschliessend 
gegen Anderungen der Oi-Komponente durch 
andere Aufrufer-Instanzen geschutzt. 

Der Ergebnis-Sperrbereich ist anschliessend 
zum Andern der Oi-Komponente fur den Auf- 
rufer exklusiv reserviert. 



Die Arten fix und reorg entsprechen in ihrer Seman- 
tik den konventionellen Arten read und write, sie be- 
ziehen sich jedoch auf Modifikationen der Adressbereiche 
(z.B. durch move). 

Der Parameter action beschreibt, wie die lock- 
Operation mit dem gewiinschten Lock umgehen soil. Er hat 
einen der folgenden Werte: 

ask Es wird lediglich nachgesehen, ob das Setzen 

eines entsprechendes Locks ohne zu blockie- 
ren moglich gewesen ware. Der zuriickgelie- 
ferte Ergebnis-Sperrbereich kann an Wettren- 
nen mit anderen Aufrufern von Lock teilneh- 
men und ist entsprechend vorsichtig zu behan- 
deln. 

try Der Lock wird atomar gesetzt, wenn es so- 

fort ohne zu blockieren moglich ist. Ansonsten 
wird die Lange 0 zuruckgeliefert. 

wait Der Lock wird gesetzt, auch wenn dazu erst 
auf die Freigabe durch eine andere Instanz ge- 
wartet werden muss. Die Rucklieferung. von 
lockecUlen = 0 ist trotzdem moglich, ins- 
besondere wenn ein Deadlock vorliegt. Das Er- 
gebnis muss daher in jedem Fall vom Aufrufer 
iiberpruft werden. 

Die Einschrankung der moglichen Ausfuhrungsfolgen 
hangt von den Kompetenzen der Nest-Implementierung ab. 
Bei singleuser brauchen keine Locks implementiert zu 
werden; multiver sion wird in Kapitel 7 behandelt. Bei 
multiuser sieht die Kompatibilitatstabelle der Operatio- 
nen folgendermaBen aus: 
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hen mOsste. Bei klassischen Transaktionen start dies nicht grundlegend, 
da die anderen Transaktionen, die dies ebenfalls versuchen. einfach mit- 
tels Rollback abgebrochen werden. Ausserhalb von Transaktionen besteht 
jedoch das Problem, dass ein Update auf die neueste Version nicht durch 
Transaktions-Abbruch erfolgen kann, sondern „von Hand" eriedigt werden 
muss (i.d.R. durch Freigabe des inzwischen veralteten Read-Locks, emeu- 
tern Lock und transfer im read-Modus). Wer diesen Modus einsetzt, 
muss also damit rechnen, dass er nicht immer funktioniert, weil es genau 
genommen eine Spekutation darstellt, bei der darauf spekuliert wird, dass 
niemand ausser der eigenen Instanz eine Modifikation der gesperrten Da- 
ten vornehmen wird. Diese Spekulation Iasst sich sicherlich auch ausser- 
halb von Transaktionen vorteilhaft zur Erhdhung der potentiellen Paralleli-- 
tat einsetzen, dies wird jedoch durch erhahte Komplexitat der Programm- 
Logik erkauft. 
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Der erste Buchstabe der Uberschrifts-Bezeichnung bezeich- 
net die Operation g=get oder 1=1 ock. Der zweite Buch- 
stabe bezeichnet die Lock-Art r=read, w=write oder 
u=upgrade. Im Falle von get bezieht sich der zweite 
Buchstabe auf den mode-Parameter. Es sind die logischen 
Adress-Zuordnungen samtlicher gehaltenen Datenblocke in 
Betracht zu ziehen, die sich mit dem angeforderten lock- 
Bereich uberschneiden. 

In der Tabelle bedeutet +, dass die Operation ohne zu 
warten durchlauft, wenn sie auf die jeweils andere stoBt, 
und - bedeutet, dass gewartet werden muss, bis die andere 
Operation aufgehoben wurde (d.h. es findet eine Einschran- 
kung der moglichen Ausfuhrungsfolge start). Das Zeichen 
* bedeutet, dass es davon abhangt, ob die andere Operati- 
on von der gleichen Aufrufer-Instanz initiiert wurde; falls 
ja, dann wird nicht gewartet (andernfalis wurde ja sofort ein 
Deadlock entstehen); falls nein, dann muss gewartet wer- 
den. An denjenigen Stellen der Tabelle, wo ein - steht, darf 
die andere Operation, wenn sie von der aktuellen verschie- 
den ist, nicht von der selben Aufrufer-Instanz ausgefuhrt 
worden sein, sondern nur von einer anderen 22 . 

Die Lock-Arten fix und reorg sollen gegen die Ef- 
fekte der spater beschriebenen adressmodifizierenden Ope- 
rationen move, clear und delete schiitzen, daher sind 
diese in der folgenden Tabelle berucksichtigt: 
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In der Oberschrift bedeutet m=move oder clear oder 
delete (irgendeine adressmodifizierende Operation). Der 
Endbuchstabef bedeutet fix, g bedeutet reorg. Wie man 
sieht, funktionieren die Adressanderungs-Sperren analog zu 
den klassischen Read-Write-Locks, nur beziehen sie sich 
ausschliesslich auf die ai-Komponenten der Zustande. 

Die Realisierung von lock und unlock ist intern so zu 
gestalten, dass auf eine Trennung in Spinlocks und Kon- 
trollfluss wechselnde Locks verzichtet wird (vgl. [K + 91, 
LA93]), und fernerhin eine Benutzung durch Unterbrechun- 
gen (interrupts) moglich ist (vgl. [KE95]). 

3.3.6 Freiwillige Selbstkontrolle des Verhal- 
tens 

Eine Nest-Implementierung garantiert durch die hier propa- 
gierten Lock-Mechanismen wettrenn-freies Verhalten und 
Schutz gegen Eingriffe anderer Instanzen, und zwar auch 
dann, wenn andere sich nicht an Locking-Konventionen 
halten. Diese Garantie nutzt jedoch einer Aufrufer-Instanz 
mit mul ti * -Verhalten nur dann etwas, wenn sie die Locks 
auch tatsachlich benutzt - wer das „vergisst*\ der ist selbst 
an moglichen Folgen schuld. Bei einem komplexeren Sy- 
stem sind jedoch Fehler, die von fehlenden oder falsch ge- 
setzten Locks verursacht werden, extrem schwer reprodu- 
zierbar und zu finden. Jede Baustein-Implementierung soil- 

22 Andernfalis stellt es einen (ggf. erkennbaren und per Fehlercode sank- 
tionierbaren) Fehler dar. 



te daher ihr Verhalten durch eine freiwillige Selbstkontrolle 
mittels folgender Tabelle priifen: 
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Hierbei bedeutet g=get und l=lock. Der letzte Buchsta- 
be hat die gleiche Bedeutung wie bei den Kompatibilitats- 
Tabellen. Die Zeilen bezeichnen die erste Operation, die 
Spalten die zweite Operation. Beide Operationen beziehen 
sich auf dieselbe Instanz, die sie aufrufen. Die Tabelle ist 
daher nicht symmetrisch wie die vorherigen Tabellen, son- 
dern zeigt die Wichtigkeit der Reihenfolge der Operatio- 
nen. In der Tabelle bedeutet !, daB die zweite Operation nur 
dann aufgerufen werden darf, wenn die erste bereits aus- 
gefuhrt wurde (und noch nicht durch eine Gegenoperation 
aufgehoben wurde). Wenn in einer Spalte mehrere ! auftau- 
chen, dann reicht es, wenn eine der ersten Operationen vor- 
her ausgefuhrt wurde. Das Zeichen & bedeutet, dass die be- 
treffende erste Operation zusatzlich ausgefuhrt worden sein 
muss, wobei eine der mit & markierten Operationen ausrei- 
chend ist. Das Zeichen bedeutet, dass die erste Operati- 
on auf gar keinen Fall vorher aufgerufen worden sein darf, 
bzw. dass sie inzwischen wieder aufgehoben worden sein 
muss. 

Obwohl diese Verhaltens-Selbstkpntrolle freiwillig ist, 
wird sie de facto als Standard fur das Verhalten aller Bau- 
steine betrachtet; Ausnahmen sind z.B. zur Inspektion ir- 
gendwelcher Zustande oder zu Statistik-Zwecken zulassig, 
sollten aber begrundet werden (z.B. damit, dass der be- 
treffende Vorgang sowieso inharent wettrenn-gefahrdet ist). 
Die Selbstkontrolle kann z.B. durch interne Verwendung 
eines Priif-Bausteins erfolgen, der alle Operations-Aufrufe 
mitiiest und bei Verletzung der Tabelle Warnungen oder 
Fehlermeldungen ausgibt, ggf. auch zu harteren Sanktio- 
nen greift. Da die Information Qber gehaltene Locks auf 
jeden Fall in der Bearbeiter-Instanz der Locks gefuhrt wer- 
den muss, bietet sich diese ebenfalls als Ort zur performan- 
ten Durchfuhrung der an sie delegierten Kontrolle an. Falls 
die Aufgabenstellung extreme Anforderungen an die Per- 
formanz stellt, kann die Selbstkontrolle zu Lasten erhohter 
Fehleranfalligkeit auch ausgeschaltet werden. 

3.3.7 get_maxlen und set jnaxlen 

get_maxlen(nest) -» len 
set_maxlen (nest , len) -> success 

Damit laBt sich die maximale Lange (maximale benutz- 
bare Adresse plus 1) eines Nestes abfragen bzw. setzen. Bei 
einigen (eher selten vorkommenden) Geraten laBt sich diese 
Lange verandern (z.B. bei Bandlaufwerken durch Schreiben 
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einer EOF-Marke oder dergleichen); bei den meisten Gera- 
ten Iiegt die Lange jedoch physikalisch fest. 

GroBere Bedeutung hat set_maxlen bei dynamischen 
Nestern, wobei sowohl Verkleinerungen als auch VergroBe- 
rungen die Semantik von delete in den betroffenen Be- 
reichen ergeben (siehe Abschnitt 3.4.3). 

33.8 Stream-IO, Pipes, Sockets und Spei- 
cherverwaltung 

Die bisher beschriebenen Elementaroperationen losen die 
Probleme des portions weisen Zugriffs, des asynchronen IO 
tiber Speicherhierarchien hinweg, und der damit verbunde- 
nen Speicherverwaltung. Dies funktioniert jedoch nur dann, 
wenn die logischen Adressen bekannt sind, an denen IO ge- 
schehen soli. Bei rein sequentiellem IO, wie er z.B. bei se- 
quentiellen Streams, Pipes oder Sockets auftritt, benutzen 
konventiohelleSchnittstellen keine Adressen in der Schnitt- 
stelle. 

^Nester lassen sich zur Nachbildung von Pipes und 
aIs Ringpuffer 23 (mit durch get_maxlen be- 
Iner Lange) auszufuhren. Logische Adressen wer- 
rder Schnittstelle verwendet, die jedoch nicht vom 
Aufrufer, sondern von der Implementierungs-Instanz der 
Nest-Operationen vergeben und verwaltet werden. Damit 
werden weitere Nutzungsarten und Kombinationen mog- 
lich 24 , insbesondere der Lookahead auf noch nicht endgul- 
tig konsumierte Daten. 

Das Problem der Atomdriffit der Reservierung ist eine be- 
sondere Eigenschaft von Pipes, Sockets und regularen Da- 
teien im Append-Modus. Parallele Write-Operationen sto- 
ren sich nicht gegenseitig und uberschreiben sich nicht, son- 
dern fuhren letztlich stets zu irgendeiner serial isierten Folge 
von Schreiboperationen (auch wenn die konkrete Reihen- 
folge i.a. nicht determiniert ist). Ebenso ist beim parallelem 
Lesen aus Pipes und Sockets garantiert, dass ein und die- 
selben Daten bei irgendeinem der Leser genau einmal an- 
kommen werden (auch wenn der konkrete Empfanger wie- 
d 5SyH^ cht determiniert ist). Auf Nester iibertragen, be- 
d^^^es, dass keine Wettrennen zwischen verschiede- 

^^^genannter ..Wraparound" des zirkularen Puffers laBt sich auch 
durch Einschieben einer move-Operation vermeiden, sobald der Platz am 
Ende des Puffers nicht mehr reicht. 

24 Getrennte Adressbekanntgabe ermdglicht u.a. eine einfoche Lfisung 
fiir ein Problem, das insbesondere bei Unix zu einer Aufbiahung der Sy- 
stemschnittstellen geruhrt hat: wenn ein Konsument unter Unix wissen 
mochte, ob Daten an einem lO-Kanal anliegen, kann er dies mit Hilfe 
der Systemaufrufe select bzw poll erfahren; i.a. kann er jedoch nicht 
die GroBe der Daten erfahren; eine Ausnahme ist lediglich die Socket- 
Schnittstelle, die Lookahead auf Datenpakete unter gewissen Umstanden 
ermoglicht. Diese historisch spater nachgeriistete Funktionalitat zeigt ein 
offenbar vorhandenes BedUrfnis nach dieser Funktionalitat auf. 

Man kann unter Unix nicht ohne weiteres Daten ..auf Verdacht" oder 
mehrmals inspizieren (Lookahead), urn dann aufgrund ihres Inhaltes zu 
entscheiden, ob man sie wirklich „konsumieren" oder zur Verarbeitung 
durch eine andere Instanz im Puffer belassen will. Dass eine solche Funk- 
tionalitat auch auf regularen Dateien und Pipes gebraucht wird. ist damn 
zu sehen, dass sie in der Standard-Benutzerbibliothek libc teHweise an- 
geboten wird. Wenn diese Funktionalitat nicht erst dort simuliert wOrde. 
sondern bereits im Kem integriert ware, dann wtirden gewisse durch die 
doppelte Pufferung im Kern und Benutzer-Adressraum bedingte Anoma- 
lien nicht auftreten. Dazu gehdrt beispielsweise. dass ein Lookahead nicht 
zwischen verschiedenen Prozessen funktioniert. die aus der gleichen Pipe 
lesen wollen. 



nen Aufrufer-Instanzen (z.B. Prozessen) bei der Inspektion 
von Anderungen in der Addressabbildung stattflnden dur- 
fen. Wenn man andererseits den Lookahead auf noch nicht 
endgultig konsumierte Daten ermoglichen will, dann muss 
man solche Wettrennen wiederum ermoglichen (es ist dann 
Aufgabe der Konsumenten, mit den damit verbundenen Ef- 
fekten korrekt umzugehen). 

Zur Losung der Atomaritat des Reservierungs-Problems 
schlage ich vor, die Operationen get_address und 
put_address einzufiihren. Die Schnittstelle sieht fol- 
gendermaBen aus: 

get_address (nest, min__l en , max_l en , 

where, lock, action) (log_address, len) 

Die beiden Langen-Parameter kennzeichnen das Minimum 
und das Maximum eines Reservierungs-iywAwc/z^. Der 
boolsche Parameter where gibt an, pb die Reservierung 
im bisher undefinierten Bereich der Adressabbildung statt- 
flnden soil (Write-Funktionalitat) oder im definierten Be- 
reich (Read-Funktionalitat). Falls action = wait ist 
und eine Reservierung der Minimallange nicht moglich ist, 
blockiert der Aufruf so lange, bis zumindest die Minimal- 
Reservierung moglich ist (langfristiges Warten). Der bool- 
sche Parameter lock bestimmt, ob mehrere Aufrufer par- 
allel jeweils einen reservierten Adressbereich erhalten dur- 
fen, oder ob weitere Bewerber bis zum nachfolgenden 
put_address warten miissen. 

Als Ergebnis wird die Adresse des nunmehr reservierten 
Bereiches zuruckgeliefert sowie seine tatsachliche Lange, 
die zwischen der Minimal- und Maximal-Anforderung lie- 
gen kann (in Vielfachen der transf er_size); bei Fehl- 
schlagen wird 0 zuruckgeliefert. DieNest-Implementierung 
sichert jeder Aufrufer-Instanz die Atomaritat der Reservie- 
rung zu, indem parallele Aufrufe von get_address in 
jedem Falle disjunkte Adressbereiche ausliefern. Der Auf- 
rufer besitzt anschlieBend Kenntnis Uber einen nur fur ihn 
exklusiv reservierten Adressbereich, mit deren Hilfe er Da- 
tenblocke lesen oder schreiben, und/oder Anderungen an 
der Addressabbildung mittels clear oder delete (siehe 
Abschnitte 3.4.2 ff.) ausfuhren kann 25 . 

put_address (nest, len) 

Hebt die Reservierung wieder auf. Jeder Aufrufer von 
get_address hat die Pflicht, einen einmal erhaltenen 
Adressbereich irgendwann wieder mittels put_address 
freizugeben; der Zeitpunkt und die Reihenfolge bleibt dabei 
prinzipiell offen. 

Die Standard-Pipe-Funktionalitat wird durch folgenden 
Ablauf erzielt: 

Leser: der Aufrufer fuhrt als erstes get_address 
aus, dann get im erhaltenen Adressbereich; 
falls die Aktualitat der Daten noch nicht 
gegeben sein sollte, folgt transfer im 
read-Modus und wait. Nach der Verarbei- 
tung der Daten folgen delete, put und 
put_address. 



25 Die atomare Reservierung fuhrt dies jedenfalls nicht selbsttatig aus. 
Es ist Sache des Aufrufers, wofilr er den reservierten Bereich benutzt. 
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Schreiber: der Aufrufer fiihrt als erstes get_address, 
dann clear und get aus. Nach der Abla- 
ge der Daten folgen transfer im write- 
Modus, put und put_address. 

Falls ein Schreiber oder Leser die Daten nicht end- 
giiltig konsumieren oder bereitstellen will, kann er auf 
delete bzw clear auch verzichten, bzw. die jewei- 
lige Adressraum-Operation durch eine Kompensations- 
Operation vor dem put_address wieder aufheberi. Ob 
und wie viele Daten tatsachlich konsumiert oder bereit- 
gestellt wurden, wird ausschlieBlich durch Anderungs- 
Operationen des Definitionsbereiches angezeigt, die von 
der Reservierung auch nach unten abweichen diirfen. Der 
Standard-Fall einer vollen Ausnutzung sollte sich durch das 
Konzept der systematischen Rekombination von Elementa- 
roperationen (vgl. Abschnitt 2.4) effizient losen lassen. 

Wenn der Parameter lock nicht gesetzt ist, dann kann 
die tatsachliche Belegung des Adressraums durch cle- 
ar bzw die Freigabe durch delete auch in einer ande- 
ren Reihenfolge stattfinden, als die Reihenfolge der Adress- 
Reservierung vorgab. Es kann sogar passieren, dass gar kein 
Iiickenlos zusammenhangender definierter Adressbereich 
entsteht, wenn einige der Aufrufer nach get_address 
auf die entsprechende Manipulation des Adressraums ver- 
zichten oder sie wieder ruckgangig machen. Dadurch geht 
u.U. die Reihenfolge-Beziehung der Datenpakete verlo- 



eine Liste von Paaren, wobei jedes Paar die logische Start- 
adresse eines definierten Bereichs und seine Lange repra- 
sentiert. Reprasentiert wird diese Liste durch ein Array von 
Paaren, das nach den Startadressen aufsteigend sortiert "e- 
halten wird. Zur effizienten Suche nach Adressen kann da- 
her beispielsweise binare Suche verwendet werden. 

Da ein solches Array in Extremfallen sehr lang werden 
kann, wird es von get_map nicht direkt zuriick geliefert 
sondern statt dessen wird ein Verweis auf eine weitere Nest- 
Instanz zuriick geliefert, die dieses Array enthalt, und von 
der nur gelesen werden darf. 
get_map(nest) nest 

Die von get_jmap zuriickgelieferte Nest-Instanz wird ad- 
jungiertes Nest genannt. Sie enthalt den Definitionsbereich 
des Onginal-Nestes in der oben beschriebenen Represen- 
tation. Adjungierte Nester haben ihrerseits auf jeden Fall 
keine Locher, d.h. ihr adjungiertes Nest hat nur noch eine 
triviale Struktur mit einem einzigen Eintrag 28 

Diese L5sung hat den Vorteil, dass die interne Ver- 
waltung des Definitionsbereiches durch lokale Baustein- 
Instanzen geschehen kann, die das adjungierte Nest di- 
rekt verwalten. Erweiterungen und Loschungen im Defini- 
tionsbereich lassen sich in diesem Fall direkt durch move- 
Operationen auf dem adjungierten Nest realisieren. Anson- 
sten diirfen Implementierungen von Nestern ihren Defini- 
Uonsbereich auc * auf beliebige andere Weise intern reali- 
ren, die bei der Pipe-FunktionaTitat notwendig ist, ande- sieren ' sofern sie ei " virtuelles adjungiertes Nest zur Verfu- 
ren Anwendungen aber die Moglichkeit einer out-of-order- gUng stellen » das sein en Inhalt auf Anforderung dynamisch 
Behandlung bietet 26 generiert. 



Wenn man die trans f er-Operationen weglasst, erhalt 
man eine nichtpersistente Semantik. Damit kann man die 
Funktionalitat eines Speicher-//ea/?jinachbilden. Daher eig- 
net sich diese Schnittstelle auch fur jegliche Speicherver- 
waltung, sogar fur interne Objekte fester GroBe 27 . 



3.4 



Elementaroperationen auf dyna- 
mischen Nestern 




jDynamische Nester enthalten alle Operationen eines stati- 
schen Nestes sowie zusatzlich die folgenden adressmodifi- 
zierenden Operationen. Sie haben mit der Luckenhaftigkeit 
des Definitionsbereich der Speicherabbildung und mit der- 
Verschiebeoperation zu tun. 

Falls versucht wird, auf Lochern im Definitionsbereich 
eines Nestes zu lesen oder zu schreiben, werden Fehlerco- 
des zuriickgeliefert. Dies unterscheidet Nester von der Se- 
mantik von Sparse Files unter Unix. Falls letztere Semantik 
gewunscht wird, ist diese relativ einfach durch einen ent- 
sprechenden Anpassungsbaustein implementierbar. 

3.4.1 getjnap 

Diese Operation liefert Informationen iiber die definierten 
Bereiche eines dyna mischen Nestes. Konzeptionell ist dies 

26 Beispielsweise zur Verwaltung von IO-Auftriigen fUr Festplatten- 
Geriitetreiber, wo Umordnungen der Reihenfolge zur Durchsatzsteigemng 
eingesetzt werden. 

27 so genonnte Objekt-Caches lassen sich sehr einfoch dadurch realisie- 
ren, dass man die Objekt-GrflBe als trans f er_size benutzt. 



generiert. 

Die im adjungierten Nest enthaltene Liste hat eine be- 
sondere Bedeutung im Falle von Geraten mit dynamischen 
Block- oder SektorgroBen (insbesondere Bandlaufwerke, 
bei denen jeder Datenblock eine individuelle GroBe haben 
kann, oder sonstige zeichenorientierte Gerate, bei denen es 
auf die Lange von einzelnen Transfers ankommt), bei Pi- 
pes und bei Netzwerk-Sockets, bei denen die PaketgroBe 
eines einzelnen Original-Eintrags vom Empfangerermittel- 
bar sem muss 29 . In all diesen Fallen reprasentiert das adjun- 
gierte Nest dicht aneinander liegende Adressbereiche (ohne 
dazwischenliegende Lucken). Damit kann jeder Verwender 
selbst entscheiden, ob er einen Unix-typischen Zugriff auf 
das Nest unter Missachtung der ursprunglichen Paket- bzw. 
Datensatzgrenzen machen will, oder ob er zuvor die Paket- 
bzw. Datensatzgrenzen im adjungierten Nest nachsehen und 
entsprechend beriicksichtigen will. 

28 Mit get^nap( 5 ) sei das zu einem beliebigen Nest s gehbnge adjun- 
gierte Nest notiert. Die n-fache Komposition der get_map-Funktion mit 
sich selbst seii mit get _jnap» notiert. Dann gilt fur n > 2: get_map»(A-) 
= geunap^+^s). Das dreifach adjungierte Nest beschreibt sich also 
selbst. 

2y Das von BSD stammende Socket-Konzept und seine Schnitistel- 
le ist heute in praktisch alien bedeutenden Betriebssystemen reah\iert 
auch in den Betriebssystemen von Microsoft, in alien modernen Unix- 
Vananten, und ist selbst in neueren Versionen von IBM-GroBrechner- 
Betnebssystemen nachgeriistet worden. Da Sockets je nach Modus unci 
Umstanden das Lesen von Paketen sowohl mit Beachtung der beim Schmi- 
ben vorgegebenen Paketgrenzen, als auch nach dem Unix-Paradigma mit 
aufgelSsten Paketgrenzen als unabhiingige Folge von Teilbldcken unter- 
statzen und verlangen, kommen ernsthafte Betriebssystem-Entwtirfe im 
Endeffekt nicht darum herum. beide Paradigmen zu unterstUtzen. Wenn 
man schon beide Paradigmen unterstUtzen muss, dann sollte dies nur ein- 
heitliche Weise, bei moglichst vielen Arten von Nestern und auf mMlchsl 
alien Ebenen geschehen. & 
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Ein dichtes Aneinanderliegen von deRnierten Bereichen 
ist auch bei persistenten Nestern moglich. Die Benutzer 
werden jedoch gebeten, derlei in der Praxis moglichst 
zu meiden, da es zu Verstandigungsproblemen mit den 
Datei-Paradigmen anderer aktueller Betriebssysteme kom- 
men konnte 30 . 

Konzeptuell gesehen ist ein Nest somit weit mehr als ein 
File unter Unix, da es untrennbar mit seinem Definitionsbe- 
reich verknupft ist, der bei der hier vorgestellten Architektur 
in einem adjungierten Nest reprasentiert wird. 

Bei der Representation eines Unix- oder Windows-Files 
in einem Nest enthalt das zugehorige adjungierte Nest nur 
emen einzigen Eintrag mit der Startadresse 0 und der Lan*e 
des Files 31 . Die mittels get_jmaxlen und set.maxlen 
zugreifbare Maximal ad resse hat hierbei nur die Funktion 
einer Sicherheitsschranke ahnlich einer Quota, die nichts 
iiber den tatsachlichen Platzbedarf aussagt und ohne wei- 
teres auch Werte wie z.B. 2 63 - 1 annehmen kann. 

3.4.2 clear 

•(nest, log_address, len,mode) 
. success 
md der Deflnitionsbereich eines Nestes an der an- 
gegebenen Stelle und Lange erweitert, soweit sich vor- 
her dort eine Liicke befand. Falls anschlieBend in diesem 
Bereich des Adressraumes gelesen wird, erscheinen Null- 
Byte-Datenblocke. 

Dies gilt auch dann, wenn vorhei bereits Datenblocke 
dem betroffenen Bereich ganz oder teilweise zugeordnet 
waren. In diesem Fall bleiben bereits mittels get aus- 
geheferte Datenblocke weiterhin verwendbar, allerdin^s 
werden spater abgesetzte oder bereits gepuffe'rte trans°- 
f er-Operationen auf diesen Blocken nicht mehr tatsach- 
lich ausgefiihrt. Nach endgultiger Freigabe durch put wer- 
den derartige venvaiste (orphane) Datenblocke sofort zum 
Speicher-Recycling verwendet. 

Da ein get auch Blocke mit Vielfachen der trans- 
fer^ize ausliefern kann, die von einem nachfolgen- 
do^^ar eventuell nur zu einem Teil betroffen sind, 
nfchtf^interne Logik der Nest-Implementierung sicher- 
st ^^ ass bei nachfolgenden Operationen (insbesondere 
put und transfer) der nicht betroffene Teil eines sol- 
chen Blocks wie ein normaler Block, der betroffene Teil 
dagegen als verwaist behandelt wird: 

Falls clear einen bereits definierten Bereich beruhrt 
oder mit ihm ganz oder teilweise uberlappt, dann flndet 
standardmaBig eine Erweiterung bzw. Verschmelzung der 
Deflnitionsbereiche im adjungierten Nest statt. Ggf. werden 
Locher auch vollstandig aufgefiillt und benachbarte Berei- 
che miteinander zu einem groBeren Bereich verschmolzen. 

Durch Setzen des boolschen Parameters mode laBt sich 
dieses Standard-Verhalten so abandern, dass genau an den 
Grenzen des clear-Bereiches Eintrage im adjungierten 
Nest so erzeugt bzw. verandert werden, dass der Bereich 
als ein einziges Datenpaket mit ggf. iQckenlosem Anschluss 

"Diner Mechanismus kann auch dazu dienen, File-Paradigmen aus an- 
deren (meist alteren) Betriebssystemen nachzubilden, die nicht das Unix- 
Paradigma vom File als Folge von Bytes verfolgen. 

In diesem Fall gilt bereits Turn > 1: geUnap"<5) = get_map"+i(s). 
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an (ggf. erst dadurch entstandene) benachbarte Bereiche er- 
scheint. Falls vorher im clear-Bereich mehrere kleinere 
definierte Bereiche gelegen waren, dann werden sie durch 
diese clear- Variante ebenfalls „platt gemacht". 

3.4.3 delete 

delete (nest, log_address , len) success 
Diese OperaUon bewirkt, dass an der angegebenen Stelle 
und Lange ein Loch im Deflnitionsbereich entsteht bzw 
bereits vorhandene Locher ggf. erweitert werden. Falls be- 
troffene Datenblocke bereits vorher mittels get ganz oder 
teilweise in Verwendung genommen worden waren, dann 
werden diese bei den IO-Operationen und beim Speicher- 
Recycling analog zu clear als verwaist behandelt. 



3.4.4 move 

move (nest, log_address , len, of f set) 

„. , ... success 
Ein durch die angegebene Adresse und Lange bezeichne- 
ter Bereich des Adressraums wird um den Offset (positiv 
oder negativ) verschoben. Der Inhalt der verschobenen Da- 
tenblocke wird hierbei nicht verandert, Iediglich die Zuord- 
nung von logischen zu physischen Adressen wird verandert 
Bereits mittels get ausgelieferte Blocke, die vollstandig im 
Quellbereich der Verschiebung liegen, bleiben samt ihren 
physischen Adressen weiterhin gultig, jedoch wird ihre in- 
terne transiente Zuordnung gemaB der Verschiebung ange- 
passt. Beim spateren put werden sie so behandelt, als hat- 
ten sie schon immer an der neuen Adresse gelegen Quell- 
und Zielbereich der Verschiebung durfen sich unabhangig 
von der Verschieberichtung uberlappen 32 ; gegeniiber f ix- 
und reorg-Locks sind grundsatzlich beide Bereiche als 
relevant zu betrachten, auch wenn sie sich nicht uberlap- 
pen. Im freigewordenen Quellbereich erscheint ein Loch 
Falls sich im Zielbereich bereits definierte Bereiche befin- 
den, werden diese „verdeckt"; bereits durch get ausgelie- 
ferte Datenblocke werden analog zu delete als verwaist 
behandelt. Eventuelle im Quellbereich vorhandene Locher 
werden mitverschoben; die Freigabe von bereits vorhande- 
nen Datenblocken im Zielgebiet erfolgt selbst dann, wenn 
ausschheBIich ein Loch dorthin verschoben wurde 33 . 

Falls vor dem move bereits Blocke mittels get ange- 
fordert worden waren, die vollstandig im Quellbereich la- 
gen, dann werden sie anschlieBend so behandelt, als hat- 
ten sie schon bei der Anforderung im Zielbereich gele- 
gen. Bei Blocken mit einer vielfachen Lange der trans - 
fer^size, die von der Verschiebung nur teilweise be- 
troffen sind, muss die interne Verwaltungslogik die interne 

32 Eine Variante von move konnte den Qbenleckten Bereich des Zielee- 
bietes in den gleichgroBen freigewordenen Bereich des Quellgebietes in 
einer einzigen atomaren Operation verschieben, so dass im EndefFekt ei- 
ne Art Rotationsoperation" ohne jeglichen Verlust von Daten ausgefUhit 
wird. Damn iSBt sich insbesondere eine Vertauschung von Adressberei- 
chen realisieren. Im Moment sehe ich fiir diese Variante nur geringe prak- 
tische Notwendigkeit, jedoch bildet diese Variante von move zusammen 
mi clear und delete eine Algebra von Operationen auf Adressraumen 
mitsenr schQnen mathematischeh Eigenschaften. 

WUrde man oo als zuliissige Quell- und Ziel-Angaben fdr die Ver- 
schiebung einfuhren, kdnnte man damit nebenbei auch die Semantik von 
clear und delete erfUHen. 



3.4. ELEMENTAROPERATIONEN A UF DYNAMISCHEN NESTERN 

■ m 

transiente Zuordnung aufspaltenund getrennt behandeln, so 
dass die einzelnen Teile bei folgenden Operationen wie z.B. 
put oder transfer so behandelt werden, als waren sie 
urspriinglich nicht am Stuck angefordert worden. 

Eine effiziente Realisierung von move ist moglich und 
wird in Abschnitt 4.1 .3 (Baustein map_simple) naher de- 
tail lie rt. 





3.4.5 get__meta 

get_meta(nest) -driest 

Zur Verwaltung von Meta-Information iiber den Zustand ei- 
ner Nest-Instanz kann dieser eine Hilfs-Nest-Instanz zuge- 
ordnet sein, die Meta-Nest genannt wird. Falls das Meta- 
Nest nicht existiert, wird ein NULL- Ken nzeichen zuriick- 
geliefert. 

Meta-Nester sind dazu gedacht, um Informationen iiber 
ein Nest bereitzustellen, analog zu Datei-Attributen oder 
Inode-Informationen (siehe [Bac86]), jedoch nicht aus- 
schlieBlich auf diese Verwendungszwecke beschrankt. 
Meta-Nester werden spater in Abschnitt 6.1 eine heraus- 
ragende Rolle bei der Einfuhrung von IVpsystemen spie- 
len, ebenso in Abschnitt 4.2 bei der Auto-Instantiierung von 
Bausteinen und in Abschnitt 4.1.5 bei den Lokalitatseigen- 
schaften von Zugrirfen auf Verzeichnis-Hierarchien. 

Ein Meta-Nest enthalt nur einen einzigen deflnierten Be- 
reich ohne Locher, der idealerweise nur relativ wenig Platz 
beanspruchen sollte (d.h. er sollte nicht zur Speicherung 
groBer Datenmengen missbraucht werden), um ein perfor- 
mantes Zugriffsverhalten sicherzustellen. Wegen der be- 
absichtigten Kleinheit sollte ein Meta-Nest eine trans- 
fer_sizevon 1 unterstutzen. 

Bei einem persistent gehaltenen (!)riginaI-Nest muss das 
zugehorige Meta-Nest, sofern es existiert, ebenfalls persi- 
stent gehalten werden. Falls absturzsichere atomare Trans- 
aktionen implementiert werden, muB das Meta-Nest beziig- 
lich dieser Semantik wie ein Teil des Original-Nestes be- 
handelt werden. 

Meta-Nester lassen sich grundsatzlich weiterhin zur Re- 
presentation statischer und dynamischer Attribute benut- 
izen; dies fuhrt zu einer Vereinfachung der zu implementie- 
renden Konzepte, macht die Anwesenheit (virtueller) Meta- 
Nester jedoch zur Pfiicht 
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Eine Baustein-Instanz ist ein Objekt, das eine beliebige, 
eventuell auch zur Laufzeit sich andernde Anzahl von Ein- 
und Ausgangen besitzt, die wiederum jeweils Instanzen von 
Nestern darstellen. 

Bausteine werden ahnlich wie in der Elektro- und Di- 
gitaltechnik als Kastehen mit linksseitigen Eingangen und 
rechtsseitigen Ausgangen gezeichnet. Als Verdrahtungsre- 
gel gilt, dass Eingange nur mit den Ausgangen anderer Bau- 
steine verknupft werden durfen und umgekehrt, wobei ein 
Eingang nur mit einem einzigen Ausgang, ein Ausgang hin- 
gegen i.A. mit mehreren Eingangen verkniipft werden darf. 

Ausgange stellen damit Nester anderen Bausteinen zur 
Verfugung, wobei deren Eingange als Konsumenten der 
von den Ausgangen angebotenen Dienstleistungen anzuse- 
hen sind; wir habeh also ein System von Produzenten und 
^^tlM^ um ^^ »rn logischen Sinne. Eine Verdrahtungs- 
I*MMM|pprasentiert eine Hierarchie-Beziehung 1 zwischen 
^^tjBrgeschalteten Baustein (Produzent der Dienstlei- 
stungjund einem nachgeschalteten (Konsument der Dienst- 
leistung). Per Konvention definieren wir als „Stromrich- 
tung" einer Verdrahtungs-Leitung die Richtung vom Produ- 
zenten zum Konsumenten; dies hat jedoch nichts mit mogli- 
chen Datenfluss-Richtungen zu tun, denn die Stromrichtung 
ist zwar gleichzeitig die logische Datenfluss-Richtung beim 
Lesen, doch die logische Schreib-Datenflussrichtung lauft 
dem entgegen (was am Anfang zu Verwirrung fuhren kann, 
ebenso die baustein-interne Weitergabe von Operations- 
Aufrufen, die intern meistens von den Ausgangen her zu 
den Eingangen verlauft). Eine Leitung stellt alle Operatio- 
nen, die am Ausgang eines Bausteins zur Verfugung gestellt 
werden, einem oder mehreren Konsumenten zur Verfugung. 

'Dies hat hohe Ahnlichkeit mit einem Schichtenmodell. Ein rein- 
rassiges Schichtenmodell ffiBt sich z.B. durch eine Kette von Baustein- 
Instanzen nachbilden. lm Unterschied zu Schichtenmodellen werden auch 
neben-UiuJige Hierarchien und graphenartige Strukturen unterstiitzt, die 
von einer Baumstruktur abweichen. Im Aligemeinen sind jedoch keine zy- 
klischen Verdrahtungen erlaubt. 




Da dies auch die Operationen get_map und ge't_meta 
umfasst, wird auf diese Weise das zugehorige adjungierte 
Nest und das Meta-Nest verfugbar gemacht. 

Sinn der Bausteine ist, verschiedene Transformationen 
sowohl des Adressbereiches als auch eventuell des Inhal- 
tes von Nestern, gelegentlich auch des zugehorigen Meta- 
Nestes oder von Nest-Attributen wie trans f er_size 
oder von Zugriffs-Modellen durchzufuhren. Durch Kom- 
bination der Bausteine zu komplexen Netzwerken erge- 
ben sich Transformationsmoglichkeiten, die mit herkomm- 
lichen Betriebssystem-Architekturen nur sehr schwer reali- 
sierbar sind. 

Bausteine besitzen mindestens eine Instantiierungs- und 
Konstruktor-Operation, mit der sich neue Instanzen des je- 
weiligen Baustein-Typs erzeugen lassen, wobei die Parame- 
ter von Konstruktor-Operationen i.d.R. baustein-speziflsch 
sind. Die Destruktor-Operation hat hingegen eine einheit- 
liche Schnittstelle. Einige Baustein-iypen haben daruber 
hinaus weitere spezifische Operationen, mit denen sich ihr 
Verhalten (etwa die Anzahl der Ein- und Ausgange) zur 
Laufzeit steuern laBt. 

Eine automatisierte Uberpriifung der Kompatibilitat der 
Kompetenzen von Ausgangen mit dem Verhalten von 
Eingangen findet bei der Verdrahtungs-Operation statt; 
beispielsweise wird das Zusammenpassen des trans - 
fer_size-Attributs uberpruft. Weitere Details dazu in 
Abschnitt 4.2. Viele der nachfolgend vorgestellten Baustei- 
ne lassen sich in verschiedenen Ausbaustufen 2 und mit ver- 
schiedenen Kompetenzen und Verhalten implementieren. 

4,1 Beispiel-Baustein-Arten 

Beim Entwurf von Bausteinen sollte darauf geachtet wer- 
den, dass moglichst wenig Redundanz zur Funktionalitat 
bereits vorhandener Baustein-Arten auftritt. Sinn der Zer- 
legung in Bausteine ist, die in einem Betriebssystem insge- 
samt zu losenden Aufgaben in moglichst viele, kleine, von- 
einander moglichst unabhangige (orthogonale) Teile und 
Zustandigkeiten aufzuspalten. 

Ich habe mich bemuht, bei der hier als beispielhaft zu 
verstehenden Zerlegung moglichst nur solche Aufgaben 
zu stellen, die auch in anderen aktuellen Betriebssystem- 
Entwurfen (einschlieBIich Netzwerk-Betriebssysteme) oder 

2 Wenn ein neu entwickelter Baustein im singleuser-Modus stabil 
muft, dann kann er schrittweise bis zur mul tiversion-Kompetenz bzw. 
-Verhalten erweitert werden. 
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in Datenbanken irgendwo auftauchen und dort mit teils ho- 
hem Aufwand ad hoc gelost werden. Damit mochte ich zei- 
gen, dass eine Komponenten-Zerlegung auf Basis der Ab- 
straktionen Nest und Baustein den Gesamtaufwand der zu 
implementierenden Aufgaben mindert, da bereits die Kom- 
bination von wenigen wiederverwendbaren Baustein-Arten 
eine machtige Funktionaiitat erzeugt. 



4.1.1 device^* 



device_ide 
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Diese Bausteine haben im Regelfall keinen Eingang 3 und 
genau einen Ausgang, womit sie den Inhalt eines Gerates 
(beispielsweise device_ide fur IDE-Festplatten) als sta- 
tisches Nest den etwaigen Konsumenten zur Verfugung stel- 
len. Im Sinne der Verdrahtungslogik der Bausteine stellen 
sie Produzenten oder auch „DatenquelIen" dar. 

Eine prinzipielle Unterscheidung zwischen Block- und 
Character-Devices wie bei Unix ist nicht notwendig, da 
der Entwurf der Nest-Operationen beide Paradigmen und 
die darin vorkommenden Betriebsarten auf uniforme Wei- 
se unterstiitzt; der Unterschied wird lediglich im Wert des 
trans f er_size-Attributs angezeigt. 

Normalerweise dienen Gerate-Treiber zum Transfer von 
Datenblocken auf Peripheriegerate und brauchen daher nur 
die Operationen statischer Nester und nur singleuser- 
Kompetenzen 4 zu implementieren. 

Eine mindestens multiuser-fahige Sonderform ist 
device_mem, die transienten Speicher ohne trans fer- 
Operationen zur Verfugung stellt, indem sie die Opera- 
tionen get_address- und put_address implemen- 
tiert. Urn Speicher mit verschiedenen trans f er_size- 
Werten verwalten zu konnen, bilden mehrere Instanzen von 
device_memeine miteinander verdrahtete Hierarchie, bei 
der sich Verwalter kleiner Granularitat den Speicher iiber 
einen Eingang bei Verwaltern mit groBerer Granularitat 
^ausleihen" (vgl. Abschnitt 5.1). Der „Urverwalter" des 
physischen Hauptspeichers besitzt den gesamten Speicher 
beim Start des Betriebssystems und hat daher keinen Ein- 
gang 5 . 



Dies ist eine konzeptuell vereinfachende Darstellung. Konkrete Hard- 
ware besitzt oft eine innere Hierarchie, etwa Peripherie-Busse wie PCI 
Oder GerSte-Busse wie SCSI. Zur Realisierung deren (Unter-)Treiber eig- 
nen sich prinzipieil ebenfalls die Abstraktionen Nest und Baustein, so dass 
der „eigentliche" Gerate-Treiber auch einen oder mehrere Eingange ha- 
ben kann, mit denen er an die weitere Unter-Treiber-Infrastruktur ange- 
schlossen wird. Weiterhin mochte ich darauf hinweisen, dass sich auch 
Hardware-Konzepte wie Memory-Mapped-IO, Grafikkarten-FramebufFer 
und dergleichen leicht und effizient durch die Abstraktion der Nester dar- 
stellen lassen. 

4 Auf dem Gebiet der Storage Area Networks (SAN) k6nnte die EinfOh- 
rung multiuser-fahiger Treiber durchaus Vorteile bringen, insbesonde- 
re fUr hBhere Redundanz und Ausfallsicherheit sorgen, eventuell auch die 
Last besser verteilen. Allerdings muss dazu das Verhalten der restlichen 
Komponenten der beteiligten Betriebssysteme mitspielen. 

5 Eine Hardware-Architekturen wie z.B. die IBM z-Serie erlauben den 
Austausch von Speichermodulen zurLaufzeit. Dies lasst sich dadurch mo- 
dellieren, dass der Urverwalter die Anzahl seiner Ressourcen andert. Dazu 
muss er notfalls bereits vergebene Ressoucen wieder zuriickfordenr siehe 
Kapitel 5. 



Eine weitere multiuser-fahigeSonderform ist devi- 
ce_r amdi sk, die eine limitierte Persistenz implementiert 
die sich nicht iiber Stromausfalle hinweg erstrecken muss 6 
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Ein buf f er-Baustein sorgt fur die Entkoppelung von Ak- 
tivitaten zwischen Eingang und Ausgang (in beide Richtun- 
gen), Er eignet sich zur Adaption des zeitlichen Zugriffs- 
verhaltens zwischen langsamen und schnellen Baustein- 
Instanzen; im Idealfall sollte er die einzige Stelle im Ge- 
samtsystem darstellen, die die Probleme der sogenannten 
„Speicherliicke" zu losen hat. 

Ein hauflger Anwendungsfall ist die Nachschaltung hun- 
ter ein device^*. Dazu sind oft nur die Operationen 
statischer Nester erforderlich, und der Eingang braucht 
nur singleuser-Verhalten zu zeigen; auch der Ausgang 
braucht nur singleuser-Kompetenz bereitzu stellen, da 
im haufigsten Anwendungsfall nur eine einzige map_*- 
Instanz nachgeschaltet wird. Es gibt aber auch Anwendun- 
gen, bei denen mindestens multiuser- Verhalten und - 
Kompetenz benotigt wird, insbesondere die Nachschaltung 
hinter einen remote-Baustein (siehe Abschnitt 4. 1 . 12). 

Bei der Implementierung des multiuser-Verhaltens 
tritt das in der Literatur bekannte Problem der Cache- 
Koharenz (vgl. [AB86, LH89, HP95]) mit einer vorgeschal- 
teten Instanz auf. Durch die in der Nest-Schnittstelle vorge- 
seheneanotify_*-Operationen (vgl. Kapitel 5) ist dies 
vergleichsweise leicht losbar. 

Wenn man buf f er-Bausteine als die einzige Stelle im 
Gesamtsystem ansieht, die die Entkoppelungs-Problematik 
des zeitlichen Zugriffsverhaltens lost, und zwar sehr effizi- 
ent lost, dann kann man auch noch einen Schritt weiterge- 
hen: man kann fast alle anderen Bausteine intern statuslos 
implementieren, oder zumindest weitgehend statuslos. Ein 
Baustein ist statuslos, wenn er zu jedem Zeitpunkt, in dem 
sich kein logischer Kontrollfluss in ihm aufhalt, destruiert 
und anschliefiend erneut konstruiert werden kann, ohne daB 
dadurch ein geandertes Verhalten von auBen sichtbar wird. 

Statuslosigkeit ermoglicht eine deutliche Reduktion der 
inneren Komplexitat vieler Bausteine im Vergleich zu kon- 
ventionellen Implementierungen, weil die Verantwortung 

6 Eine mflgliche Verklemmung des Gesamtsystems durch im Normalbc- 
tneb nicht zurOckforderbare (quasi-persistente) Datenbldcke muss vermie- 
den werden. Eine einfoche LOsung dafUr ist die Forderung, dass die Sum- 
me der Maximallttngen aller device^ramdisfc-Instanzen den verfilg- 
baren Hauptspeicher nicht Uberschreiten darf. Altemativ dazu kann auch 
das Verfahren von Habermann [Hab69] angewandt werden, mit dem ei- 
ne Uberbuchung der vorhandenen Hauptspeicher-Ressourcen prinzipicl! 
mfiglich ist (jedoch wcgen des damit verbundenen Wanens unakzeptablc 
Auswirkungen auf das von Benutzern erwartete Verhalten von interaktiven 
Anwendungen oder von Realzeit-Anwendungen haben kann). 
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zur korrekten Aufbewahrung der internen Zustandsinforma- 
tion an einen untergeordneten Baustein delegiert wird; da- 
her ist Statuslosigkeit hochgradig erstrebenswert. Sie setzt 
allerdings voraus, dass Zugriffe iiber eine dermaBen ent- 
koppelte Schnittstelle/atf nichts kosten. Durch standard- 
mafiige Benutzung von Prozeduraufrufen als Schnittstellen- 
Mechanismus und durch die Zero-Copy - Arc hitektur (vgl. 
Abschnitt 2.8.2) wird dies ermoglicht. 

Zum Caching von Datenblocken wird der Hauptspei- 
cher genutzt; dieser muss von mehreren buf f er-Instanzen 
geteilt werden. Die damit verbundene Problematik konnte 
auBerhalb des Verdrahtungs-Sy stems der Bausteine gelost 
werden (erstes Bild). Die folgende Losung hat jedoch Vor- 
teile: 

Der mit slow bezeichnete Eingang soli wie bei der er- 
sten Variante zur Entkoppelung der Zugriffs-Haufigkeiten 
und -Anzahlen dienen. Das mit fast bezeichnete 
Eingangs-Nest enthalt den gesamten Status des Puffers; da- 
zu gehort neben den Inhalten der zu puffernden Daten- 
blocke auch die transiente Zuordnung zwischen logischen 
l^y^rysischen Adressen und der Aktualitats-Status. Der 
^jjy -Baustein wird dadurch selbst vollkommen status- 

^Wmit dies zu guter Performanz fuhrt, muss fast sehr 
schnellen Zugriff bieten. Die Idee besteht darin, an diesem 
Eingang wahlweise ein device_ranidisk anzuschlie- 
Ben, oder irgendein anderes relativ schnelles Gerat; bei 
der Pufferung von Zugriffen auf extrem langsame Band- 
laufwerke 7 kann dies beispielsweise auch ein Nest sein, 
das auf Festplatte vorgehalten wird. Letztlich macht buf- 
fer nichts anderes, als das zeitliche Zugriffsverhalten des 
fast-Eingangs an den Ausgang weiter zu reichen. Die 
am fast-Eingang angeschlossene Instanz wird mit ge- 
ringeren Datenmengen belastet als beim slow-Eingang 
vorhanden sind; bei Speichermangel darf sie Speicher- 
Ruckforderungs-Antrage(vgl. Kapitel 5) stellen. 

Die explizite Benutzung von device_ramdisk als 
fast-Eingang hat den weiteren Vorteil, dass die Proble- 
me der Speicher-Ruckforderung, sowie der im Gesamt- 
syp^gemischt verwendeten unterschied lichen trans - 
fc^:|Bpe-Blockgr6Ben ausschlieBIich dort zu losen sind. 
^J^ind von absehbaren Fortschritten in der Hardware- 
Entwicklung ist zu erwarten, dass zukunftige Rechner ganz 
andere interne Speicher-Hierarchien besitzen werden, als 
sie heute ublich sind. Das Baustein-Konzept ermoglicht ei- 
ne flexible Anpassung an geanderte Rahmenbedingungen. 
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Friiher gait die Grundregel: je mehr Kapazitat ein Peripheriegerat be- 
reitstellt, desto langsamer ist es. Zum Zeitpunkt der Niederschrift dieser 
Arbeit haben billige als Massenprodukte hergestellte Festplatten die 100- 
GByte-Grenze durchbfochen und damit die gleiche Grdfienordnung wie 
Bandlaufwerke erreicht (vielleicht noch mit Ausnahme weniger sehr teurer 
High-End-Modelle). Auch die Medienkosten pro GByte nShern sich lang- 
sam derselben GroBenordnung. Ich erwarte, dass sich ahnliche Verschie- 
bungen der momentan herrschenden Speicher-Hierarchien auch in Zukunft 
ereignen werden. 



Aufgabe dieses Baustein-Typs ist, ein statisches Nest in 
ein dynamisches umzuwandeln. Es gibt daher nur einen 
Eingang (der meist nur singleuser-Verhalten 8 zu im- 
plementieren braucht) und einen Ausgang, der im Falle 
von Netzwerk-Betriebssystemen mindestensmultiuser- 
Kompetenz bereitstellen sollte; die Herstellung dieser Kom- 
petenz kann aber auch an eine nachgeschaltete oder interne 
adaptor_*-Instanz (siehe Abschnitt 4. 1 .8) delegiert wer- 
den. 

Es lassen sich verschiedene Arten von map_*- 
Bausteinen realisieren, die ihre Aufgabe mit jeweils ande- 
ren internen Realisierungsverfahren losen und an spezielle 
Last- und Benutzungsmodelle angepasst sind. Als Beispie- 
le werden nun zwei mogliche Realisierungen beschrieben, 
map_simple und map_simple_delta. 

Die Umwandlungs-Aufgabe wird speziell bei 
map_simple folgendermaBen erledigt: es wird an- 
genommen, dass die MaximalgroBen des Eingangs- und 
Ausgangs-Nestes annahernd gleich sind, und dass der Kon- 
sument am Ausgang nur Anforderungen in BIockgroBen 
stellt, wie sie von der MMU fur die virtuelle Speicher- 
verwaltung gestellt werden (typischerweise 4KByte oder 
8KByte). Das trans f er_size-Attribut des Ausgangs- 
Nestes wird also auf eine derartige BlockgroBe gesetzt. 
Dies bedeutet, dass alle Operationen, insbesondere auch die 
move-Operation, nur in Vielfachen dieser TransfergroBe 
erfolgen durfen. Damit liegt eine effiziente Realisierung 
bereits auf der Hand: man benutze eine Tabelle, die 
eine Abbildung der Blocknummern bzw -Adressen des 
Ausgangs-Nestes auf diejenigen des Eingangs-Nestes reali- 
siert. Diese Tabelle ist groBenordnungsmaflig etwa urn den 
Faktor 1000 kleiner als die GroBe des umzuwandelnden Ne- 
stes, verursacht also einen Platz-Overhead von etwa einem 
Promille, der sinnvollerweise am Anfang des Eingangs- 
Nestes vorreserviert wird. Alle Operations-Aufrufe, die 
etwas mit den virtuellen Adressen zu tun haben (get und 
ggf. lock / unlock) und die vom Ausgang her ankom- 
men, werden nach Ubersetzung durch diese Tabelle an den 
Eingang durch gereicht. Die move-Operation wird durch 
eine Verschiebung innerhalb der Tabelle realisiert, die aus 
den bereits dargestellten Grunden etwa urn den Faktor 1000 
weniger kostet, als wenn man move durch Unmengen 
von Block-transfer- und Kopieroperationen im statischen 
Eingangs-Nest realisiert hatte (was z.B. ein Baustein mit 
dem Namen map_braindead besorgen konnte). Diese 
Eigenschaft laBt sich dazu ausnutzen, urn den Aufwand 
weiter zu senken: wenn man die Tabelle wiederum in einem 
eigenen privaten Nest realisiert, kann dieses wiederum mit 
Hilfe einer beliebigen anderen raap_* -Instanz verwaltet 
werden, die lediglich die trans f er_size-GranuIaritat 
der Tabellenelemente unterstutzen sollte (beispielsweise 
map_simple_delta, map_.br a indead, oder eine 
Kombination aus map__simple mit einem nachgeschal- 
teten adaptor..*, der in Abschnitt 4.1.8 beschrieben 
wird). Bei giinstiger Wahl und Kombination der Bausteine 
zu mehrstuflgen Kaskaden lassen sich damit die Kosten 

"Die Herstellung von multiuser-Eingangen ist moglich, nber je 
nach gewahlter internet Struktur u.U. aufwendig. Auch bei Client-Server- 
Anwendungen ist es sinnvoll, ein statisches Nest erst mittels map_* in ein 
dynamisches umzuwandeln, bevor es z.B. mittels remote exportiert wird 
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insbesondere bei sehr groBen Nestern nochmals um einige 
Zehnerpotenzen senken. 

Eine Adressubersetzung verursacht nach langerem Be- 
trieb mit vielen move-, clear- und delete-Operationen 
ein Phanomen, das in der Literatur iiber Dateisysteme als 
Fragmentierung (vgl. z.B. [MJLF84, McK96]) bekannt ist 
Dieses Phanomen beschreibt die Tatsache, dass eine hohe 
Lokalitat von Zugriffen auf der Ausgangsseite des map- 
Bausteins nicht unbedingt in eine hohe Lokalitat der Zu- 
griffe auf der Eingangsseite ubersetzt wird, da die Tabel- 
le die Adressen ahnlich wie bei Hash-Verfahren kraftig 
durcheinander wiirfeln kann. Ein Konsument erwartet je- 
doch, dass Schreib- oder Leseauftrage, die in zusammen- 
hangender und aufsteigender Adress-Reihenfolge gegeben 
werden, mit deutlich besserer Performanz ausgefuhrt wer- 
den als zufallig verteilte Zugriffe 9 . Zur Losung dieses Pro- 
blems stehen mehrere bekannte Verfahren zur Verfiigung, 
die aus der Literatur iiber Dateisysteme analog iibertrag- 
bar sind, beispielsweise intelligente Allokations-Strategien 
und Defragmentierungs-Laufe. Durch das Background-IO- 
Konzept (Abschnitt 2.8.3) wird insbesondere eine Defrag- 
mentierung im Hintergrund des Iaufenden Betriebes stark 
erleichtert, ohne die Abarbeitung der Benutzeraktivitaten 
merklich zu storen. Ich erwarte, dass die Anwendung 
ganz einfacher und primitiver Verfahren wie die bestan- 
dig angestrebte Herstellung einer Identitats-Abbildung oder 
„Beinahe-Identitats-Abbildung 10 " sehr gute Resultate lie- 
fern wird, sofem dies im Hintergrund mittels Background- 
IO geschieht. 

Wenn man davon ausgehen kann, dass eine Defrag- 
mentierung im Hintergrund dafur sorgt, dass die Adress- 
ubersetzung „nur wenig" von einer Identitats-Abbildung 
abweicht, dann IaBt sie sich auch auf folgende Weise rea- 
lisieren, die ich map_simple_delta nenne: 

Statt einer Tabelle fester GroBe wird eine Liste (bzw. 
ein als Ringpuffer ausgefiihrtes Array oder dergleichen) der 
bisher ausgefuhrten Operationen benutzt, die etwas an den 
Adress-Zuordnungen andern. Dadurch geht die Durchfuh- 
rung von move, clear und delete rasend schnell, weil 
nur ein Eintrag in die Liste gemacht werden muss, so dass 
sich im Endeffekt ein Log der durchzufuhrenden Operatio- 
nen ergibt (falls im Log auch alle IO-Operationen aufge- 
zeichnet werden, entsteht ein ahnlicher Effekt wie in Log- 
strukturierten Dateisystemen, vgl. [R091]). Die Uberset- 
zung einer Adresse kann nun grundsatzlich dadurch erfol- 



9 Diese Erwartungshaltung ist bei genauer Betrachtung letztlich nur 
durch die Tatsache gerechtfertigt, dass die heutige Externspeicher-Technik, 
vorallem diejenige von Festplatten, schlechte Lokalitatseigenschatten auf- 
grund der mechanisch bewegten Teile besitzt (siehe auch die in der Litera- 
tur ausflihrlich diskutierte so genannte „SpeicherlUcke M ). In absehbarer Zu- 
kunft werden hoch-kapazitive Externspeicher mit nicht nur deutlich hohe- 
ren Datentransferraten und geringeren Latenzzeiten, sondern auch besse- 
ren Lokalitatseigenschaften zu konkurrenzfahigen Preisen verfugbar sein, 
beispielsweise holographische Speicher oder auf Magnet- oder Quantenef- 
fekten beruhende hoch-kapazitive Halbleiterspeicher. Aus diesem Grund 
dtirfte die Diskussion zur Behebung des Fragmentierungs-Problems nur 
begrenzte Bedeutung haben. 

,0 Hierunter fallen z.B. Verschiebungen um konstante Offsets, wie sie 
auf jeden Fall notwendig werden, wenn filr die Obersetzungstabelle bei- 
spielsweise am An fang des Eihgangs-Nestes Platz reserviert wird. Ich 
mechte hier keine saubere mathematische Definition solcher Abbildun- 
gen geben, sondern eine Charakterisierung von Eigenschaften, die fur den 
Architektur-Entwurf relevant sind. 



gen, dass in dieser Log-Liste nachgesehen wird, ob irgend- 
welche Operationen eingetragen wurden, die etwas an ei- 
ner gegebenen Adresse andern; diese Anderungen werden 
dann in der richtigen Reihenfolge quasi virtuell nachvollzo- 
gen. Dieses einfache Verfahren fiihrt naturlich nur dann zu 
akzeptabler Performanz, wenn die Liste moglichst kurz ge- 
halten wird. Eine Mdglichkeit zur Kiirzung der Liste besteht 
darin, dass solche Operationen, die sich gegenseitig ganz 
oder teiiweise aufheben bzw. die sich durch eine einzige 
Ersatz-Operation mit gleicher Semantik ersetzen lassen, aus 
der Liste entfernt und ggf. durch die Ersatz-Operation er- 
setzt werden (Prinzip der [Compensation von Operationen). 
Eine andere, in der Praxis auf Dauer unumgangliche Mog- 
lichkeit besteht darin, dass im Hintergrund Verschiebungen 
und Umordnungen durch Background-IO stattflnden, durch 
die Eintrage in der Liste uberflussig werden 1 1 . 

Zu erwahnen ist weiterhin, dass map_simple_delta 
nicht nur Blocke mit relativ groBer Granularitat wie bei 
Platten-Devices oder MMU-Sei ten verwalten kann, sondern 
auch kleinere trans fer_size-Werte bis hinunter zu 1 
unterstutzt. Der Ausgang unterstutzt automatisch die glei- 
che Granularitat, wie sie vom Eingang vorgegeben wird, al- 
lerdings kann es vorkomrnen, dass eine get-Anforderung 
miteinem hohen Vielfachen der transf er_size nur mit 
einem geringeren Vielfachen mdglich ist. Dies ist in der 
Schnittstelle fiir Nester ausdriicklich so vorgesehen, und es 
ist die Aufgabe eines jeden Konsumenten, mit diesem Fall 
umgehen zu konnen (wobei er sich das Problem auch durch 
Vorschalten eines adaptor^* vom Hals schaffen kann). 

Ein map_*-Baustein muss auch die Operation 
get_meta sowie die Operationen auf dem Meta- 
Nest implementieren. Ein Meta-Nest sollte im Regelfall 
eine transf er_size von 1 unterstutzen, was sich 
durch interne Verwendung eines adaptor_*-Bausteins 
(Abschnitt 4. 1.8) erzielen IaBt. 

Wichtig ist ferner, dass map_*-Bausteine unbedingt die 
Eigenschaft der Abstunfestigkeit besitzen sollten. Mit die- 
sem Begriff soli umschrieben werden, dass eine jederzeiti- 
ge Trennung des Bausteins von seinem Eingang bzw. ein 
Verlorengehen von transf er-Operationen (z.B. bei ei- 
nem plotzlichen Stromausfall, der zum Verlust der vorge- 
schalteten fluchtigen buf f er-Informationen fuhrt) nicht 
die Integritat der Adressubersetzung zerstoren darf. Wenn 
man nicht auf die Performanz- Vorteile von Pufferung in 
fluchtigem Speicher verzichten will, muss man damit le- 
ben, dass der Zustand auf dem persistenten Hintergrundme- 
dium standig dem Zustand im fluchtigen Speicher hinter- 
herhinkt, so dass bei unerwartet auftretenden Storungen Da- 
ten und damit Informationen verloren gehen. Bekannte L6- 
sungen dieses Problems 12 stellen Log-basierte Schreibver- 

n Unabhangig davon sollte map_simple_delta nur bei solchen 
Last-Charakteristiken angewandt werden, bei denen nur relativ seltcn 
Verschiebe-Operationen angefordert werden (was bei vielen Anwendun- 
gen durchaus erwartet werden kann), oder aber bei denen umgekehrt 
extrem htiufige Verschiebungen, dafUr aber nur relativ wenige Adress- 
Zugriffe vorkomrnen, so dass der AdressUbersetzungs-Aufwand bei den 
amortisierten Kosten nur wenig ins Gewicht fdllt. 

I2 Eine weitere L6sung, niimlich die Konsistenzpriifung nach AbslDnen. 
halte ich wegen ihrer schlechten Reparatur- Eigenschaften und vor allem 
wegen ihrer Komplexitat fiir unpraktikabel (als Standard-Mittel zur Be- 
hebung der Effekte von AbstUrzen; in absoluten Notsituationen sieht es 
dagegen anders aus). Die Komplexitat einer Konsistenzpriifung kann we- 
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fahren dar; entweder in Form separater^Ugs oder in Form 
sogenannter Log-strukturierter Speicher. Zur Unterstiitzung 
dieser Verfahren wurde in Abschnitt 3.3.1 der Parameter 
depend eingefuhrt, mit dem sich die Reihenfolge von 
Schreiboperationen teilweise vorgeben lasst. Absturzfestig- 
keit laBt sich fernerhin. als Teil von ACID-Transaktionen 
implementieren, fails man diese bereits in einer entspre- 
chenden map_*-Variante bereitstellen mochte. Eine wei- 
tere Moglichkeit stellt die Vorschaltung eines eigenen po- 
wer saf e-Bausteins analog zu [dJ93] dar, der in isolierter 
We.se nur die Absturzfestigkeit als Strategie implementiert 
und auf die Erweiterung statischer Nester auf dynamische 
verzichtet. 

Die Funktionalitat von map_* laBt sich sicher auch 
mit Dutzenden weiterer Verfahren zur Adress-Ubersetzung 
herstellen, die eventuell Vorteile bei bestimmten Last- 
Charaktenstiken bringen konnen. Zu nennen sind hier bei- 
spielsweise Tries, balancierte Baume, B-Baume, Fuzzy Ha- 
shing, und andere. Meine Ausfuhrungen sollten plausibel 
gemacht haben, dass effiziente Realisierungen des Konzep- 
tp C dynamischen Nester moglich sind. 
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Dieser Anpassungs-Baustein schneidet einen zusam- 
menhangenden Teil-Adressraum aus seinem Eingangs- 
Adressraum aus und stellt ihn unverande'rt am Aus- 
gang zur Verfugung, wobei die Adressen standardma- 
Big wieder bei 0 neu beginnen. Wird der ausgeschnitte- 
ne Adressraum als Ganzes verschoben, dann wirkt sich 
das nicht auf den Gastgeber-Adressraum aus, ebenso 
umgekehrt bei Uberstreichung einer move-Operation im 
Gastgeber-Adressraum iiber den gesamten ausgeschnitte- 
n WBtMii ch ( Tran sparenz). 

^^Jplementierung ist relativ einfach, da auBer ei- 
n^^i-men Adressubersetzung und -Uberprufung nichts 
zu machen ist und alle Operationen vom Ausgang an 
den Eingang durch gereicht werden kOnnen. Es sind zwei 
grundlegende Varianten von Selektoren moglich, selec- 
tor_persistent und selector_tmp, die sich dar- 
in unterscheiden, ob die Ausschnitts-Adressen und -Lan°en 
sowie deren Anderungen persistent festgehalten werden 
sollen oder nicht. Im ersteren Fall wird Hilfsinformation im 
Meta-Nest des Eingangs gehalten, mit der die Startadresse 
und die Lange relativ zum Gast-Adressraum auf Dauer fest- 
gehalten wird, so dass eine Destruktion des selector mit 
anschlieBender Reinstantiierung wieder den alten Zustand 
ergibt. 

4.1.5 dir_* 



gen der mfjglichen Zersplitterung eines Nestes in sehr viele kleine Flicken 
nach Art eines SchweizerkSses sehr groB werden. 



Ein Baustem dieser Art benutzt das Eingangs-Nest als ei- 
ne Art Sammel-Container, urn mehrere von einander unab- 
hangige Ausgangs-Nester daraus zu bilden. Die Ausoanos- 
Nester werden bei Bedarf durch die baustein-spezifische 
Zugnffsoperation create neu erstellt; bereits fruher er- 
stellte werden durch lookup erneut instantiiert, sofern sie 
mcht bereits instantiiert sind. Unterschieden werden die 
verschiedenen moglichen Ausgangs-Instanzen durch einen 
Suchschlussel, der als ein zusammenhangenderDatenblock 
ubergeben wird. Zur Abfrage alter vorhandenen persistent 
gespeicherten Schliisselwerte dient ein spezieller Ausgang 
der Verzeichnis-Nest genannt wird, der im Regelfall eine 
trans fer_size von 1 unterstutzt, und von dem nur ge- 
esen werden darf. Ein Verzeichnis-Nest stellt ein Nest mit 
luckenlos liegenden Datenpaketen dar, wobei jedes Paket 
genau einen der vorhandenen Suchschlussel enthalt Die 
Schliisselwerte konnen, . mussen aber nicht nach irgendei- 
nem internen Kriterium sortiert gehalten werden. Loschun- 
gen von Schlusselwerten und der zugehorigen Ausgangs- 
Nest-Instanzen Iassen sich als baustein-spezifische Ope- 
ration und/oder durch eine delete-Operation auf dem 
Verzeichnis-Nest realisieren. Hierbei ist die aus Unix be- 
kannte Methodik zu bevorzugen, dass zwischen statischen 
und dynamischen Referenzen unterschieden werden soll- 
te, und dass ein Ausgang und sein Speicherplatz erst dann 
tatsachltch freigegeben werden sollen, wenn keine dynami- 
schen Referenzen mehr vorhanden sind. 

Aus dieser Beschreibung diirfte klar geworden sein, dass 
damit ein Verzeichnis realisierbar ist, wie es in konven- 
tionellen Betriebssystem-Architekturen von Dateisystemen 
zur Verfugung gestellt wird. Ein dir_* stellt jedoch kei- 
ne Verzeichmsbaum-Hierarchiezur Verfugung, sondern ah- 
nelt eher dem flachen Index einer Datenbank. Dennoch las- 
sen sich Verzeichnisbaum-Hierarchien sehr leicht herstel- 
len: am Ausgang einer dir_*-Instanz braucht lediglich ei- 
ne weitere dir_*-Instanz angeschlossen zu werden und 
so weiter. Auf diese Weise kann der Dateisystem-Baum 
(bzw. ein momentan instantiierter Teilbaum davon) direkt 
als Baumstruktur von Baustein-Instanzen mit der zu»eh6ri- 
gen Verdrahtung dargestellt werden. Wenn man die in Ab- 
schnitt 4.2 vorgestellte Auto-Instantiierung von Bausteinen 
benutzt, dann braucht man sich als Benutzer nicht urn die 
dynamische Herstellung dieser Baumstruktur zu kummern 
da dies automatisch geschieht. 

Im Vergleich zur Funktionalitat klassischer Dateisyste- 
me ermoghcht dieses Konzept eine wesentlich flexiblere In- 
stantnerung und Verdrahtung, da man beispielsweise 
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• fur jedes Verzeichnis^ndividuell verschiedene 
Baustein-Typen einsetzen kann, beispielsweise 
dir_simple fiir kleine Verzeichnisse, dir_hash 
fur solche mit besonders schneller lookup- 
Funktionalitat, oder dir_btree fur solche mit 
besonders guten Lokalitatseigenschaften trotz riesiger 
Ausdehnung 

• Datenkomprimierungs-, Datenverschliisselungs- und 
sonstige Anpassungs-Bausteine wie adaptor_* und 
andere auf beliebigen Hierarchieebenen (automatisch) 
dazwischen schalten kann 

• auf Konzepte wie Mounts und Mount-Tabellen ver- 
zichten kann, da dies von einem redirect-Baustein 
ubernommen werden kann 

• ebenso auf Konzepte wie Loopback-Devices verzich- 
ten kann, indem lediglich ein map_* zwischenge- 
schaltet wird 

• nahtlose Integration mit der Funktionalitat von Daten- 
banken moglich ist: dazu zahlt nicht nur der spater vor- 
gestellte transact ion-Baustein, sondern auch die 
Moglichkeit, spezialisierte Bausteine wie beispiels- 
weise dir_f ixed_keysize einzusetzen, bei de- 
nen eine Uniformitat der Schlussellangen zugunsten 
besserer Platzausnutzung erzwungen wird 

• eine virtuelle Herstellung von Verzeichnisinhalten 
durchfuhren kann, beispielsweise mit einem Bau- 
stein dir_proc fur die Funktionalitat von /proo 
Dateisystemen, oder dir_join zur Herstellung der 
Funktionalitat der aus der Datenbank-Welt bekannten 
Join-Operation aus dem Daten-Inhalt mehrerer anderer 
Nester. In diesem Fall konnen dir_*-Varianten ent- 
stehen, die gar keinen oder mehrere Eingange besitzen, 
was sich u.U. mit dem althergebrachten Konzept eines 
Dateisystem-Baums nicht auf intuitive Weise model- 
lieren laBL 

Die grundlegende Funktionsweise von dir_*- 
[Bausteinen mochte ich am Beispiel einer Realisierung 
von dir_simple erlautern. Es werden insgesamt 
drei verschiedene Regionen von zusammenhangenden 
Adressbereichen benutzt, urn die Container-Funktionalitat 
zu realisieren. Dies sind 

• die Index-Region, 

• die Meta-Region, 

• dieDaten-Region. 

Diese Regionen werden innerhalb des Eingangs-Nestes 
und des Eingangs-Meta-Nestes angelegt, wobei die Daten- 
Region auf jeden Fall im Eingangs-Nest, die Meta-Region 
auf jeden Fall im Eingangs-Meta-Nest, und die Index- 
Region wahlweise in einem der beiden Nester liegen kann 
(sinnvollerweise sollte die Zuordnung von der GroBe des 
Index abhangig gemacht werden). 

<*ir_simple betrachtet diese Regionen jeweils als 
kompakt zusammenhangende Teil-Nester und benutzt die 
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am Eingang zur Verfugung stehenden move-Operationen, 
urn Einfugungen und Loschungen von Index-Werten durch- 
zufuhren, sowie die an den Ausgangen ankommenden mo- 
ve-Operationen u.a. an den Eingang weiter zu reichen 
Dies bedeutet fiir die get_maxlen-Werte der Ausgange! 
dass ihre Summe kleiner-gleich des get_maxlen-Wertes 
des Eingangs sein muss* Die interne Realisierung von 

f 7 lr - L S3 f Ple braucht sich nicht um die Bereitstellung und 
Verschiebung von Platz zu kiimmern, da diese Funktiona- 
litat bereits am Eingang verfugbar ist. Um die Funktionali- 
tat eines instantiierten Ausgangs zu erfiillen (mit Ausnahme 
von set_maxlen, das abgefangen werden muss), konnen 
interne Instai\zen von selector verwendet werden. 

Die Reihenfolge von Eintragen ist bei dir_simple 
in alien Regionen gleich: wenn beispielsweise ein Eintrag 
in der Index-Region ganz am Anfang bei der ersten Po^ 
sition eingefugt wird, dann wird in der Meta-Region und 
m der Daten-Region ebenso verfahren und dort jeweils 
Platz im Adressraum geschaffen. In diesem Fall, oder wenn 
sich beispielsweise die GroBe eines Ausgangs-Nestes durch 
set_jnaxleri so stark andert, dass Uberschneiduno en 
drohen, wird der gesamte restliche Adressraum in einem 
Rutsch verschoben; wegen der Transparenz-Eigenschaftder 
intern verwendeten s elect or-Bausteine merken die be- 
reits instantiierten Ausgange nichts davon. 

Der Index-Bereich wird bei dir_simple direkt im 
g eichen Format abgespeichert, wie sie der Verzeichnis- 
Nest-Ausgang verlangt. Andere dir_*-Arten konnen 
selbstverstandlich davon abweichen. 

Die Ausgange eines dir_*-Bausteins sollten minde- 
stens multiuser-Kompetenz bereitstellen. Hierfur *ibt 
es mehrere Moglichkeiten: die interne Realisierung k5nn- 
te z.B. nur durch singleuser-Verhalten erfolgen (was 
den Entwurf ein klein wenig vereinfacht) und die mul- 
tiuser-Kompetenz an den Ausgangen durch eine ad- 
apt or_*-Instanz zur Verfugung stellen. Fur die Einsatz- 
gebiete von Netzwerk-Betriebssystemen ist jedoch durch- 
gehendes multiuser-Verhalten vorteilhaft. Dies ist bei 
dir_simple reiativ einfach zu erfiillen, da die oben 
beschnebene Realisierung weitgehend statuslos erfolaen 
kann. Bei statuslosen Realisierungen ist die Hinzunahme 
von multiuser- oder multiversion-Verhalten ein- 
fach, da lediglich alle potentiell konfiikttrachtigen Opera- 
tionen durch lock / unlock-Paare zu klammern sind. 
Die einzige konflikttrachtige Operation bei den Ausgangs- 
Nestern ist set_maxlen, die bei vernunftigem Entwurf 
nur selten aufgerufen werden sollte; alle anderen Opera- 
tionen auBer Modiflkationen in der Index-Region brauchen 
keine zusatzlichen Klammern und laufen unverandert oder 
nur wenig verandert durch. 



Konzeptionell entspricht diese Einschrankung dem auch bei kon- 
7£Tl ? T ISy 5 emen vorkommenden Zwang, dass die Summe des 
Platzbedarfs a Her abgespeicherten Dateien nicht die GesamtgrdBe des 
Dateisystems Ubersteigen darf. Falls in einer dirJ>-Hierarchie sehr groBe 
? vorkommen, deren Nut 2 un & sgrad eine heuristisch 
Prnhi^^K^ u " terschreitet bei haufigem Vorkommen 2 um 

t * kann, dass ein Adressraum mit 64 Bit Breite nichl mehr 
fUr die Summe aller vorkommenden Adressraum-GrQBen ausreicht). drnn 
kann eine Verkleinerung der virtuellen Adressraum-GroBen durch einen 
zwischengeschalteten map_*-Baustein erreicht werden. 
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Diese recht einfache Realisierung hat sehr gute Lokali- 
tatseigenschaften: das Lokali tats- Verhal ten eines Ausgangs 
wird direkt an den Container beim Eingang weitergereicht. 
Falls kieine Verzeichnisse so realisiert sind, dass die Index- 
Region im Meta-Nest des Eingangs liegt, dann enthalt das 
Meta-Nest im Falle von rekursiv verschachtelten Verzeich- 
nissen an der Wurzel die gesamte Baumstmktur aller Indi- 
zes, die im Vergleich zur Summe aller DateigroBen urn ei- 
nige GroBenordnungen kleiner ausfallt (zumindest bei tibli- 
chen durch menschliche Nutzer verursachten DateigroBen) 
und allein wegen dieser geringen Lokalitat der Ausdehnung 
einen schnellen Zugriff erlaubt (wobei das Caching des 
transitiv vorgeschalteten buf f er-Bausteins separate Kon- 
zepte wie Inode- oder Namens-Caches uberflussig macht). 

Die Zuordnung der Index-Region zu einem der beiden 
Eingangs-Nester ist eine Strategie-Entscheidung, die in je- 
dem Einzelfall anders getroffen werden kann; sehr groBe 
Index-Regionen lassen sich auch in das regulare Eingangs- 
Nest verlagern, so dass die Lokalitat des Meta-Nestes mrjg- 
lichst wenig verschlechtert wird. 

J^^weitere strategische Entscheidungsmoglichkeit fur 
fl^v^litats-Verhalten besteht darin, einige oder alle der 
S Wn miteinander zu verschmelzen. Dies kann insbe- 
scl^re bei der Verquickung der Index- mit der Meta- 
Region Vorteile bringen, sofern die Meta-Daten der Aus- 
gange nur wenig Platz beanspruchen. Der von Hans Rei- 
ser in reiserf s propagierte effiziente Zugriff auf sehr 
kieine Datei-GroBen (wie z.B. bei der Modellierung einzel- 
ner Felder von Datensatzen einer Datenbank mit Hilfe von 
„Mini-Dateien") IaBt sich ggf. durch eine Verschmelzung 
von Index-und Daten-Region erreichen, bzw durch eine 
fallweise dynamische heuristische Zuordnung zu einer der 
Regionen. Ferner kann man bei der Representation der Fel- 
der von Datensatzen einer Datenbank einen funktionalitats- 
maBig stark eingeschrankten Baustein-Typ dir_record 
einsetzen, der die immer gleiche Index-Struktur von Re- 
cords gleichen Aufbaus und die ebenfalls immer gleichen 
Metadaten (in denen die Feldnamen und Feldlangen und 
weitere Attribute gespeichert werden) nicht in der Index- 
Rg^^i^d er einzelner Instanz abspeichert, sondern per Re- 
f m m einer gemeinsamen externen Quelle bezieht und 
d^^^f einen vernachlassigbaren Platz-Overhead bei je- 
der einzelnen Instanz verursacht. 

Durch diese Beispiele sollte plausibel geworden sein, 
dass spezielle Anforderungen, die bisher oftmals als An- 
reiz zur Entwicklung aufwendiger und umfangreicher 
Dateisysteme mit trickreichen internen Implementierungen 
dienten, durch ein Baustein-Konzept mindestens ebenso gut 
abgedeckt werden konnen. Die hier vorgestellte Baustein- 
Zerlegung verteilt die in Dateisystemen vorkommenden 
Problematiken und Funktionalitaten auf mehrere Baustein- 
Arten, isoliert sie voneinander, und ermoglicht vorher un- 
bekannte Kombinationen. Einige der Moglichkeiten wer- 
den auf einfachere Weise als mit stapelbaren Dateisyste- 
men (vgl. [HP94, HP95]) gelost, da nicht mehr zwischen 
verschiedenen Ebenen wie „Dateien" versus „Dateisystem- 
Baume" unterschieden wird. 
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Dieser Baustein stellt in gewisser Hinsicht eine inver- 
se Operation zu selector bzw dir__* dar: mehrere 
Eingangs-Nester erscheinen in einem Ausgangs-Nest und 
werden dabei adressmaBig nebeneinander aufgereiht. Uber 
Parameter bzw. Meta-Informationen wird festgelegt, ob 
sich ein Eingangs- Adressraum luckenlos an seinen Vorgan- 
ger anschlieBen soil (so dass eventuelle Lucken am En- 
de des Vorgangers und am Anfang des eigenen Nestes 
zusammen geschoben werden und move-Operationen des 
Vorgangers mit vollzogen werden), ob der Anschluss uber 
get_maxlen erfolgen soil, oder ob er ggf. unter Lucken- 
bildung an festen Adressen „festgenagelt" erscheinen soli 
(analog zu selector). Weitere Spielarten sind denkbar. 

Uber den spater besprochenen Mechanismus der generi- 
schen Operationen lassen sich Eingange zur Laufzeit hin- 
zufugen und entfernen. 

Ein wichtiges Anwendungsgebiet von union ist die Zu- 
sammenstellung verschiedener Regionen bzw. „Segmen- 
te" in virtuellen Adressraumen oder Schutzbereichen, bei- 
spielsweise die Einteilung in Code-, Stack- und Datenseg- 
mente, sowie in Mappings anderer Nester. Verschiedene 
Mapping-Arten lassen sich durch Vorschalten von Anpas- 
sungsbausteinen wie cow (Abschnitt 4.1.10) realisieren. 

4.1.7 mmu * 
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Dieser Baustein besitzt genau einen Eingang und kei- 
nen Ausgang 14 , ist also im Sinne der Verdrahtungslogik ein 
reiner Konsument. Er stellt die Schnittstelle zur Memory- 
Management- Unit (MMU) der Rechner-Hardware dar. Das 
Nest wird hierbei 1:1 15 in einen virtuellen Adressraum um- 
gewandelt, der sich uber Kontrollflusse direkt durch Ma- 
schinenbefehle des Proz essors adressieren lasst. 

I4 In Wirklichkeit hat er auch einen Ausgang, namlich den virtuellen 
Benutzer- Adressraum. Dieser hat jedoch aus Hardwaregrunden nicht mehr 
dieselbe Schnittstelle mit den hier vorgestellten Grundoperationen. Im ab- 
strakten Sinne Tuhrt ein Prozessor-MMU-Gespann dennoch die gleichen 
Grundoperationen aus: Hauptspeicher-Zugriffe des Prozessors lassen sich 
als Kombinationen von get- und put- mit trans f er-Operdtionen mo- 
dellieren; eine MMU betreibt abstrakt gesehen eine eingeschrankte Art der 
Virtualisierung, wie sie ein dynamisches Nest bereitstellt. 

15 Falls der logische Adressraum eines Nestes grQBer als der virtuelle 
Adressraum eines Prozesses ist (z.B. bei 32Bit-Hardware), dann wird nur 
ein Teil des logischen Nest-Adressraums fiir den direkten Zugriff durch 
Maschinenbefehle umgesetzt. 





4. / . BEISPIEL-BAUSTEIN-ARTEN 

Die Reahsierung dieses BaRfeins ist im Vergleich zu 
konventionellen Implementierungen relativ einfach: wenn 
ein Seitenfehler auftritt, wird der betroffene Datenblock 
mittels get und nachfolgendem transfer im read- 
Modus vom Eingangs-Nest angefordert und in die Seiten- 
Tabelien der MMU eingetragen. Beim Austragen wird 
put, im Falle geanderter Seiten davor auch noch trans- 
fer im write-Modus mit geringer Hintergrund-IO- 
Prioritat aufgerufen. 

Uber die spater besprochene notify_*-Schnittstelle 
erhalt mmu_* Kenntnis von durch die Speicherverwaltung 
zur Freigabe vorgesehenen physischen Datenblocken, so- 
wie von beispielsweise durch move-Operationen invalide 
gewordenen Adressbereichen und tragt sie wie soeben be- 
sprochen aus 17 . Hierauf konnen sie evtl. beim nachsten Sei- 
tenfehler gleich wieder angefordert werden, was aber relativ 
geringe Verzogerungen zur Folge hat, sofern sich die Seite 
in Wirklichkeit noch im zentralen LRU-Cache der transitiv 
vorgeschalteten buf f er-Instanz befindet. Solche Riickfor- 
derungen konnen daher aufVerdacht und jederzeit von der 
Speicherverwaltung an zentraler Stelle 18 ausgelost werden, 
ohne die Aktivitaten eines Beriutzerprozesses merklich zu 
storen. Dadurch ergibt sich eine fortlaufende Altersbestim- 
mung innerhalb der Working-Sets (vgl. [Den68, Den71]) al- 
ler vorhandenen virtuellen Adressraume, was dem Effekt 
des bekannten Second-Chance-AIgorithmus zur Seitener- 
setzung ahnelt. Als Nebeneffekt werden geanderte Seiten 
fruhzeitig auf Verdacht mit Hintergrund-Prioritat ausgela- 
gert , so dass bei einer spater tatsachlich eintretenden Spei- 
cherknappheit eine Chance besteht, dass die Seite inzwi- 
schen nicht wieder modifiziert wurde und daher sofort recy- 
celt werden kann, ohne auf die Beendigung von IO warten 
zu mussen. * 

In einem mmu_*-Baustein braucht keine wie auch immer 
geartete spezielle Paging-Strategie mit verschiedenen Mo- 
di und Abhangigkeiten von Mapping-Arten implementiert 
zu werden, was bei konventionellen Implementierungen 
den Lowenanteil an Komplexitat ausmacht. Diese Aufga- 
ben einschlieBlich der Persistenthaltung privater Mapping- 
Segmente werden von vorgeschalteten Bausteinen iiber- 
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,6 0blicherweise beniJtigt MMU-Hardware einen Hilftspeicher fur die 
Seitentabellen. Dieser ist hier nicht als eigener Eingang ausgeftihrt, da ei- 
ne andere Verdrahtung als mit device_mem aus HardwaregrUnden meist 
nicht mdghch ist. 

l7 Trotz der Notwendigkeit, Hilfsspeicher fiir die Seitentabellen einzu- 
setzen. arbeitet eine mmu_*-Instanz logisch gesehen statuslos: man kann 
jederzeit die gesamte Seitentabelle freigeben. ohne dass ein Schaden (au- 
Ber evtl Peiformanz-Verschlechterung) eintritt, da die danach unweiger- 
hch auftretenden Seitenfehler den Status der Tabelle wieder aus dem 
Emgangs-Nest soweit notwendig rekonstruieren werden 

Nur diese Stelle hat die voile Obersicht Uber die momentane Speicher- 
situation und kann einigermaBen verlfcslich einschStzen. wie hoch zuktlnf- 
tige Speicher-Anforderungsraten ausfallen kdnnten oder ob die Situation 
unkrmsch ist. Die RUckforderungen aufVerdacht lassen sich damit den ak- 
tuel en Lastverhaltnissen anpassen, so dass unnStiger Overhead minimiert 
wird. 

Iv lrn Vergleich zu konventionellen Strategies die mit der Auslagerung 
oftmals erst bei bereits eingesetzter Speicherknappheit beginnen, fuhrt dies 
pJ^Tu e >; h f h fem lO^Verkehn Da dieser jedoch mit Hintergrund- 
Pnontat abgewickelt wird, start er laufende Aktivitaten so gut wie gar 

20 Ein konventionelles Paging auf Hintergrundspeicher stellt bei der hier 
vorgestellten Architektur kein eigenstandiges Konzept dar. Private Seg- 
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Damit em mmu.^Baustein am Ende einer Baustein- 
Hierarchie steheri darf, muss die ubliche Trennung in Spin- 
locks und schedulende Locks aufgehoben werden (sie- 

JLp P 9 K LA9 ,e ] S0WiC AbSChnitt 33 5 >- Dies «« ^ 
SMP-Rechnern (Symmetric Multiprocessing) notwendi- 

urn mehrere mmu_*.Instanzen auf verschiedene Prozessd- 
ren verteilen zu konnen oder mehrere auf verschiedene Pro- 
zessoren verteilte Kontrollflusse auf der gleichen mmu_*- 
Instanz laufen zu lassen. Weiterhin ist erforderlich. dass 
Seitenfehler-Unterbrechungen die Nest-Operationen aufru- 
fen durfen (siehe [KE95] sowie Abschnitt 3.3.5). 

Die Realisierung von Schutzbereichen ist ebenfalls Auf- 
gabe von rnmu_*. Dazu ist eine Verknupfung mit der 
Kontrollfluss-Implementierung notig, die am besten ausser- 
nalb der regularen Baustein- Verdrahtung gelost wird da 
sie davon unabhangig ist (dies gilt ebenfalls fur die An- 
bmdung an die Unterbrechungen) 21 . Verschiedene Schutz- 
bereiche lassen sich am einfachsten durch Zuordnen ver- 
schiedener Mandate (vgl. Abschnitt 2.7) und unterschied- 
hcher Behandlung in untergeordneten check^-Instanzen 
implementieren. Damit werden mmu_*-Instanzen zu Ver-" 
waltern derjenigen Mandate, die mit den Schutzbereichen 
zu tun haben. 



4.1.8 adaptor^* 
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Es handelt sich urn einen Anpassungs-Baustein mit 
nur einem Eingang und einem Ausgang, der zwischen 
Nestern mit verschiedenen Kompetenzen und Vernal- 
ten wie beispielsweise verschiedenen trans f er_size- 
Attributwerten vermittelt und ubersetzt. 



mente werden stets als temporare Nester ausgefiihrt, die auf Massenspei- 

t!Z fu t\ r rd l n *. Im Fa1Ie V '° n Stack *Segmenten sind sie am' An- 
rang (beinane) leen bei wachsender GrOBe wird neuer Platz mittels cle- 
ar nachgefordert; die Auslagerung ihres lnhaltes kann spekulativ durch 
Background-IO erfolgen. 

2, Mitte der 1990er Jahre wurden im Fachgebiet der Betriebssvsteme 
besonders viele Diskussionen urn Kern-Gr6Cen und urn Grenzen zwi- 
schen Kern und „Benutzerbereich M geftthrt. Ich vermeide den BegHff ei- 
nes Betnebssystem-Kems, da er oft mit monolithischen Strukturen asso- 
znert wird. In der hier vorgestellten Architektur kann es mehrere Ker- 
116 1? K°Z e ,^ nelIen Sinn geben: beis P«lsweise kann die Anbindung 
an die MMU-Hardware getrennt von der Kontrollfluss-Verwaltun- er- 
folgen, ggf. auch in unterschiedlichen Schutzbereichen erfolgen Wenn 
von einem bestimmten Hardware-Mechanismus in einem System nur 
ein einziges Exemplar vorhanden ist (beispielsweise eine gemeinsame 
Unterbrechungs-Sprungtabelle in einem Multiprozessor-System). dann er- 
gibt sich fiir die zugehOrige Verwaltungs-Software auf natiirliche Weise 
nur eine einzige Verwaltungs-Instanz. Bei prinzipiell voneinander unab- 
hhngigen Hardware-Einheiten kann es jedoch durchaus mehrere verschie- 
dene Verwaltungs-Instanzen geben, die man in konventioneller Temino- 
logie mehrere voneinander unabhSngige Mikro-Kerne nennen kdnnte Ei- 
ne derartige Modularisierung bringt insbesondere bei der Anpassun^ an 
geanderte oder erweiterte Hardware-Komponenten Vorteile. Diese Proble- 
matik tritt insbesondere durch die fortschreiteride technische Entwicklung 
bei Geratetreibern auf und wird bei vielen Minimalisierungs-Ansatzen von 
Kernen wie z.B. der Exokernel- Architektur [EK095] nur unzureichend ge- 
lost. 
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TTEL4. BAUSTEINE 



4,1.8.1 Adaption zwischen verschiedenen Zugriffs- 
Modellen 

Wie der Tabelle 3.1 auf Seite 22 zu entnehmen ist, gibt es 
folgende Falle, in denen kein AnschluB von Eingangen an 
die Ausgange anderer Bausteine moglich ist: 

1. Der Ausgang hat zu geringe Kompetenzen, um die 
Anforderungen durch das Verhalten der Eingange ab- 
decken zu konnen. 

2. Ein Eingang unterstutzt nur singleuser- Verhalten 
und vertragt sich daher nicht mit anderen Eingangen. 

Fur jeden dieser Falle schlage ich vor, eine adaptor-Art 
einzufuhren, die das jeweilige Problem lost. Fall 1 lasst 
sich beispielsweise durch adapt or_multi losen, der die 
am Eingang nicht vorhandenen Lock-Operationen nachim- 
plementiert. Zur Herstellung der multiuser-Kompetenz 
brauchen die restlichen Operationen nur durchgereicht zu 
werden. Etwas aufwendiger ist die Herstellung der mul- 
|sion-Kompetenz, da in diesem Modus von jedem 
pn Datenblock potentiell mehrere Versionen ins 
^ oracht werden miissen und verwaltet werden mus- 
senTn diesem Fall ist es sinnvoll, einen weiteren tmp- oder 
f ast-Eingang analog zu buffer bzw zu cow (siehe Ab- 
schnitt 4.1.10) einzufuhren, der die zusatzlichen Versionen 
und die damit verbundene Statusinformation enthalt. 

Zur Losung des Falls 2 schlage ich vor, einen Bau- 
stein adaptor ^synchronize einzufuhren. Dieser kann 
einen Eingang mit multiuser- oder multiversi- 
on- Verhalten voraussetzen, da diese Funktionalitat notfalls 
durch adaptor_multi bereitgestellt werden kann. Da 
an jedem Ausgang immer nur ein einziger Konsument mit 
singleuser- Verhalten angeschlossen werden darf, muB 
adaptor_synchronize entsprechend viele Ausgange 
haben, die ggf. zur Laufzeit nachtroglich instantiiert oder 
geloscht werden miissen. 

Die Problematik von adaptor_synchronize be- 
steht^jarin, daB jeder Ausgang die Illusion erhalten muB, 
V H einzige Konsument einer Nest-Instanz, der An- 
d^^^durchfuhrt. Eine solche Illusion wird auch von 
klSflPffen Datenbank-Transaktionenerzeugt. Zur Herstel- 
lung dieser Illusion ist daher prinzipiell auch der Bau- 
stein transaction (Abschnitt 4. 1 . 1 1 ) geeignet. Aus der 
Transaktionstheorie ist bekannt, dass eine vollstandige Iso- 
lation der Teilnehmer bei beliebigen, nicht vorhersagbaren 
und edit parallelen Aktionen verschiedener singleu- 
ser -Teilnehmer nicht moglich ist, ohne die Gefahr von 
Deadlocks oder Rollbacks in Kauf zu nehmen. Daher schla- 
ge ich eine Aufteilung der Funktionalitat vor: echte Paral- 
lelitat soli durch transaction ermoglicht werden; eine 
eingeschrankte und leichter zu implementierende Form der 
Illusion von singleuser-Verhalten wird durch adap- 
tor_synchronize hergestellt. Dies geschieht folgen- 
dermassen: 

Wir nehmen an, daB die Konsumenten an den Ausgan- 
gen statuslos arbeiten, d.h. sie fordern Datenblocke mittels 
get nur fur einen relativ begrenzten Zeitraum an und ge- 
ben sie moglichst bald wieder mittels put frei. Bei vol- 
liger Statuslosigkeit kann man damit rechnen, dass jeder 



Konsument recht bald alle seine Blocke wieder freigeben 
wird, oder dass zumindest eine vollstandige Ruckforderung 
mittels notify_*-Operationen (siehe Kapitel 5) mdglich 
ist. Unter dieser Voraussetzung laBt sich eine einfache Stra- 
tegie durch Locks implementieren, indem zu einem Zeit- 
punkt jeweils nur ein einziger Ausgang ZugrifF auf den 
Status des Eingangs erhalt; die anderen miissen solange 
warten, bis dieser samtlichen Status zuruckgegeben hat. 
Sobald irgendwelche Anforderungen durch einen anderen 
Ausgang ankommen, wahrend irgendein Status bereits ver- 
geben ist, dann versucht die adaptor_synchronize- 
Implementierung, den anderweitig vergebenen Status mit- 
tels notify^* wieder baldmoglichst zuruckzubekom- 
men 22 . Dies schrankt die Parallelitat leider sehr stark ein, ist 
aber einfach zu implementieren, vermeidet Deadlocks und 
kommt ohne Rollback-Operationen aus, die bei echt paral- 
lelen Transaktionen und vorher nicht bekanntem Zugriffs- 
verhalten nicht vermeidbar 23 sind. 

Die Konsequenz aus dieser Misere ist meines Erachtens, 
dass man das singleuser-Programmiermodell vermei- 
den sollte und Konsumenten mit explizitem multiuser- 
oder multiversion-Verhalten 24 (Kapitel 7) ausstatten 



Dies zeigt eine gewisse Ahnlichkeit zu den appartunistischen Locks, 
die insbesondere von Microsoft eingesetzt werden [OpL]. Opportunist!- 
sche Locks brauchen jedoch nicht unbedingt gewiihrt zu werden, und sie 
werden bei Bedarf gebntchen, d.h. sie werden mit brutaler Gewalt entzo- 
gen. Das in Abschnitt 5.3 propagierte Modell ermoglicht dies in Extrem- 
fallen zwar auch, verfolgt aber im Normalfall die Idee, dass ein Konsens 
Uber die Verteilung von Locks hergestellt werden sollte. Opportunistische 
Locks stellen dagegen ein eigenstandiges Konzept dar, das neben den „nor- 
malen" Locks alternativ oder zusatzlich zur Performanz-Steigerung exi- 
stiert. In dieser Hinsicht unterscheidet sich der hier vorgestellte Ansatz zu 
dem von Microsoft grundlegend. 

23 Ein Ansatz zur Vermeidung von Deadlocks in Datenbanken ist hm ver- 
vatives Unking (siehe z.B. [GR93, VGH93]), bei dem alle von einer Trans- 
aktion benutzten Ressourcen einmalig am Anfang atomar angefordert wer- 
den miissen (vgl. auch das „Handwerker-Problem M in [Jur73], das eine Ver- 
allgemeinerung des bekannten Philosophen-Problems [Lam74] darstellt); 
dies setzt jedoch entweder genaue a-priori-Kenntnisse iiber das zukGnfti- 
ge Verhalten voraus, Oder es schrankt die Parallelitat extrem stark durch 
unnbtige Spekulationen auf spater meistens doch nicht wirklich genutzte 
Ressourcen ein. Bei vorher nicht bekanntem Verhalten der Transaktionen 
fiihren inkrementell nach tats&chlichem Bedarf gesetzte 2-Phasen-Sperren 
zu einem Deadlock-Problem, das sich a priori nicht vermeiden liiflt (die 
posteriori-Erkennung ist dagegen relativ einfach; damit werden jedoch un- 
vorhersehbare Rollbacks in Kauf genommen). Deadlocks Jassen sich zwar 
durch halbgeordnetes (zyklentreies) Setzen von Locks vermeiden, doch 
auch daftir muss man das zukiinftige Verhalten der Transaktionen a prio- 
ri kennen, was in der Praxis nur selten gegeben sein diirfte. Wenn man 
Rollbacks wie bei einigen Betriebssystem-Anwendungen unbedingt ver- 
meiden muss, und/oder wenn man das zukiinftige Verhalten von Konsu- 
menten nicht kennt, dann hilft im allgemeinen nur, das Scheduling durch 
Anfordern eventuell spater doch nicht wirklich benQtigter Locks einzu- 
schriinken, d.h. den mdglichen Parallelitatsgrad zu senken. Daher ist es 
von immenser Wichtigkeit. solche Locks zu verwenden, die sich gegen- 
seitig mOglichst wenig stOren. Das multiversion-Modell (Kapitel 7) 
kann hierzu ebenfalls einen Beitrag leisten. 

24 Deadlocks kflnnen nicht nur bei Transaktionen, sondern auch bei 
multiuser- oder multiversion-Verhalten von Anwendungen auf- 
treten, die mit der Anwesenheit paralleler Aktivitaten umgehen kSnnen 
(z.B. code_reen tran t aus Abschnitt 2.6). Ich sehe Deadlocks nicht 
als dem Transaktions-Paradigma inharent, sondern der Parallelverarbei- 
tungauf gemeinsamen Daten schlechthin. Im Unterschied zumWassischen 
Transaktions-Paradigma, das die Auswirkungen und Foigen von Parallel- 
verarbeitung vor den Konsumenten zu verstecken sucht, macht das sing- 
leuser- undmultiuser-Modell diese Problematik explizit. Dies stellt 
zwar h6here Anforderungen an die Programmierer, ermoglicht aber feiner 
gesteuerte Reaktionen auf Falle von Deadlocks, z.B. indem ein Prozess 
ein Signal erhalt oder zur RUckgabe eines einzelnen Locks gebeten oder 
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sollte, warm immer es mogli«r( so fern man Wert auf Par- 
allelitat, Skalierbarkeit und Performanz Iegt) 25 . In diesem 
Sinne .st adaptor_synchronize nur als Notbehelf zu 
verstehen und einzusetzen. 



4.1.8.2 Adaption zwischen verechiedenen trans - 
f©r_size-Werten 

Im Id rJ f p" S K °, ,lter \ sich B^tein-Implementierungen nicht 
um das Problem kiimmern miissen, dass die trans- 
ferase eines Ausgangs mit derjenigen eines Einganes 
zusammenpassen muss. Diese Umwandlungs-AufgabesoM- 
te an adaptor,* delegiert werden konnen. 

Tmn f A " 8 "T ei f n ka " n M vorkomm en> dass die beteiligte 
TransfergroBen ke.ne Teiler voneinander bilden. Dieser Fall 
teucht ,n der Praxis kaum auf, weil aus guten Grunden nur 
Zwe.erpotenzen* als feste TransfergroBen benutzt werden. 
rails er dennoch auftreten sollte 27 , kann man sich auf fol- 
gende We.se behelfen: man bestimme den ggT (groBter ee- 
memsamer Teiler) der beiden vorkommenden TrLsfergro- 
l iT a „H ann SCha ' te , man 2wei aaaptor_*-I„stanzen "inter- 
Z df IVotT ^ V ° n dCr ^"^-TransfergroBe 
auf den ggT hinunter transformiert, die zweite vom fiE T 
w.eder auf d.e AusgangsgroBe hoch transformiert. Im Fol- 
genden beschranke ich mich daher auf die Annahme, dass 
eine der be.deh TransfergroBen ein Vielfaches der anderen 
darstellt. Es s.nd zwei Falle zu unterscheiden: 

1. Hochtransformation von einer kleinen trans- 
rer_size am Eingang zu einer groBeren am Aus- 
gang 

2. Hinuntertransformation von einer groSen trans- 
fer_size am Eingang zu einer kleineren am Aus- 
gang 

Bei der Hochtransformation besteht das Problem, dass der 
Konsument an seinem Eingang und damit auch am Aus- 
gang des adaptor,* erwartet, dass eine get-Operation 
einen physisch zusammenhangenden Datenblock mit min- 
destens seiner TransfergroBe liefert. Da am Eingang des 
adaptor * e.ne kleinere TransfergroBe eingestellt ist 
braucht der dort angeschlossene Produzent nicht unbedingt 
Datenblocke m.t d.eser GrSBe und/oder nicht unbedingt an 
entsprechend ausgerichteten Adressgrenzen im physischen 
Hauptspe.cherzu hefern (allerdings wird jedem Produzen- 
ten geraten, dies dennoch zu erftillen, wenn es im Einzelfall 
ohne groBere Kosten mbglich ist). 

gezwungen wird. ohne dass deswegen gleich der Totschlag-Hammer eines 
Rollbacks geschwungen werden muss "mnmer eines 

Verwendung von Transaktionen sehr nutzlich muitiuser- 
P{att TnlT n ™'." krUmmen " SektorgrfiBen kommen vor, z.B. alte re 
»n ^? und « m S e m °derne dazu kompatible Spezial-Festplatten 
von IBM d,e zur Abspeicherung von ISAM-Informationen gedatfS 

Betnebs ~<» "urderrohe ungepuflerte Zugriff 



Im Allgemeinen ist es wiinschenswert, dass der Eino.„ 
Eine von einem adaptor^ hcigestcllre phvsische K„ 

Z££EX£Z2^ - * 

8 ? n u U Crer Betrachtu "g °es Problems fallt auf dass 
die Herstellung von physischen Kopien eventuell die ChT 
ce b.rgt, die mogliche Paralle.itat von Operanone^ dadurch 
zu erhohen, dass die verschiedenen Versbnen ausdrull c," 
fur em multiversion-Modell am Ausgang genutet we 
den, auch wenn der Eingang nur multiuser VertaTten 
weiterreicht. Eventuell bietet es sich .0^^2225 
von adaptor_multi gleich hier mit zu integrieren bzw 

F^L 0 ?-™ 1 ^ g,CiCh mU der HochtraSra'tio J: 
Fah.gkeit auszustatten, so daB ein einziger Baustein-Tvn 
beide Aufgaben erledigt. oaustein- lyp 

Zur Hinuntertransformation: hier besteht das Problem 

der TransfergroBenunterschiede nicht, da eine kleinere teT 
bare TransfergroBe die Bedingungen der groBeren be eit 
von selbst erfullt. Bei der Weitergabe physlscher Adre sen 
an den Ausgang ist lediglich zu beacht^ dass d eVe ' 
halb ernes Blocks liegen kOnnen, der vom Eingang geKe- 
fert wurde. Bei der Riickgabe mittels put muss erne* sol 
che phys.sche Adresse wieder auf die^rarTsTer size 
de Emgangs normiert werden, was durch Divisionen und 
Multtpl.kat.onen, bei Zweierpotenzen auch durch Ausmas 
k.eren von Adressbits erfolgen kann Ausmas- 
Die Hinuntertransformation hat jedoch mit einem Pro- 
blem zu kampfen, das bei der Hochtransformation nicht exi 
er'STsT d ° rt ^ Symmetrie ^"den bereiu von setb 
erfullt ,st. die move-, clear- und delete-Operationen 
konnen vom Konsumenten am Ausgang in kleinefen Portio- 
nen angefordert werden, als sie vom Produzenten am Ein- 

DuScI?T 8g T hWerde " 

SSSSSlM d ' eSCr °,f erati ° nen a " den Produzenten im 
Ailgemeinfall leider nicht moglich 

ZurLSsungdieses Problems konnte ein adaptor * die 
move-Operabonkompl ettneu implementieren ohnedavon 

ROckforderung mittels der soiiter LZZZ* . &lt * oderdass e ™ 

megHch ist. tfurften V^c^^T^ ^.en ^r*^" 0 ^" 
mtlssen aber die Operationen auf Nes^ if? 1 Da " 
einen Verschiebemech^Lsmurnuf Adl Sf ^ 
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Gebrauch zu machen, dass der Eingan^ereits ein dyna- 
misches Nest bereitstellt. Dies widersprache jedoch dem 
Ziel, die Bausteine zur „moglichst orthogonal en* 4 Zerlegung 
der in Betriebssysternen vorkommenden Aufgaben einzu- 
setzen. Was bedeutet jedoch „moglichst orthogonal"? 

Fur die Beurteilung der Orthogonality und Homogeni- 
tat eines Baustein-Verhaltens sehe ich als wichtiges Kri- 
terium, ob eine Transformation wieder durch eine riick- 
iaufige Transformation aufgehoben werden kann, oder zu- 
mindest bis auf einen konstanten Rest aufgehoben wer- 
den kann (Prinzip der Kompensierbarkeit). Dies wiirde be- 
deuten, dass eine Hinuntertransformation mit nachgeschal- 
teter Hochtransformation auf die ursprungliche trans - 
f er_size nichts am Inhalt eines Nestes andern sollte, al- 
so insgesamt eine idempotente Abbildung darstellen sollte. 

Leider ist dies aus informationstheoretischen Griinden in 
vollkommener Reinform nicht moglich: Um die Aufteilung 
emer gegebenen festen Anzahl von Nutzbytes auf einen 
ebenfalls festen groBeren Adressraum mit Lochern zu ver- 
walten, muss irgendwo Platz fur die Darstellung dieser Zu- 

«sinformation aufgewandt werden. Wenn man den Nut- 
I auf den groBeren Adressraum irgendwie (z.B. zufal- 
■ iner Art Schweizerkase) verteilt, dann gibt es fur die 
hi solcher moglichen Verteilungen um so mehr Mog- 
lichkeiten, je kleiner die transf er_size gewahlt wird 
(der Schweizerkase darf bildlich gesprochen immer kleine- 
re Locher und auch mehr Locher enthalten, obwohl er we- 
der sein Gewicht noch sein Volumen andert). Welche dieser 
vermehrten Moglichkeiten konkret vorliegt, muss irgend- 
wo gemerkt und abgespeichert werden, was aus informati- 
onstheoretischen Griinden einen Platzbedarf zur Folge hat, 
der mit immer kieinerem transf er_size zumindest im 
Worst Case ansteigt 29 . Hieraus folgt, dass es i'm Allgemei- 
nen nicht moglich ist, die transf er_size nach unten 
zu transformieren, ohne dass irgendwo zusatzlicher Platz 
fur die Speicherung der nunmehr feineren Abbildungsmog- 
lichkeiten fur den Definitionsbereich des Nestes verbraucht 
wird. 

^Dies bedeutet jedoch nicht, dass zusatzlicher Platz in al- 
■^en verbraucht werden muss. Ich kann von einer Hin- 
(lsformation folgende wunschenswerte Eigenschaft 

FaTls am Ausgang der Hinuntertransformation nur solche 
Operationen ausgefiihrt werden, die auch ohne die Hinun^ 
tertransformation stattfinden konnten, weil sie (zufalliger- 
weise) die Bedingungen der groBeren transf er_size 
am Eingang bereits erfiiilen, dann sollte am Ausgang 
der Hinuntertransformation derselbe Nest-Zustand sichtbar 
sein, ais ware die Hinuntertransformation nicht vorhanden. 
Dies bedeutet u.a., dass in diesem Fall kein Platz fur in- 
terne Verwaltungsinformationen abgezwackt werden darf 
(der Sachverhalt als solcher kann im Meta-Nest mit gerin- 
gen Platzkosten vermerkt werden). Eine derartige Hinun- 
tertransformation stel lt in gewissem Sinn eine Verfeinerung 

^Dieses Argument lauft parallel zu demjenigen aus der Theorie Uber 
Komprcssionsverfahren, das besagt, dass eine verlustfreie Datenkompres- 
mm von n Ausgangs-Bits stets Kodierungen enthalten muss, die ISnger 
als n sind, wenn einige Kodierungen kiirzer als n ausfallen sollen. Die. 

I'fbt dieTo^ "iTf 2U verschledene Eingangs-Kodierungen 
gibt die in 2» verschiedene Ausgangs-Kodierungen zu Ubersetzen sind, 
da die Kompress,on in alien Fallen wieder rilckgangig machbar sein soil 
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des Eingangs-Nestes am Ausgang zur Verfugung. 

Zu realisieren ist eine solche Verfeinerung im Prinzip da- 
durch, dass nur die Unterschiede zu der groberen Eingangs- 
struktur intern verwaltet werden. Bei dieser Verwaltung tritt 
u.a. das in der Literatur bekannte Problem des internen Ver- 
schnitts auf, fur das es mehrere Losungsansatze gibt 30 . Auf 
weitere Details mochte ich in dieser Arbeit nicht eingehen. 

4.1.9 redirect 
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Dieser Baustein realisiert die Funktionalitat von Hard- und 
Softlinks 31 , sowie von Mount-Punkten und -Tabellen. Er hat 
zwei Eingange und einen Ausgang. Vom ersten Eingang 
wird standardmaBig das Meta-Nest (falls dieses leer sein 
sollte, auch das Daten-Nest) abgefragt, ob es einen Pfad im 
Auto-Instandierungs-Netzwerkenthalt. Der zweite Eingang 
wird daraufhin mit dem angegebenen (ggf. noch zu konstru- 
lerenden) Ausgang automatisch verbunden, der dann wie- 
derum am Ausgang unverandert zur Verfugung steht. Wei- 
tere Details sind in Abschnitt 4.2 erklart. 

4.1.10 cow 
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merged 



Dieser Baustein realisiert die von konventionellen privaten 
Mappings bekannte Copy-on-Write-Strategie. Er hat zwei 
Eingange, die mit orig und trap bezeichnet sind, sowie 
einen mit merged bezeichneten Ausgang. 

Im initialen Zustand ist das mit tmp bezeichnete 
Eingangs-Nest leer, und am mit merged bezeichneten 
Ausgang erscheint exakt derselbe Nest-Zustand wie am 
orig-Eingang. Die Aufgabe besteht in der Isolation des 
orig-Eingangs von alien Anderungen, die vom Konsu- 
menten hinten am merged-Ausgang in Auftrag gegeben 
werden. Jegliche Anderungen am Nest-Inhalt des Ausgangs 
oder an seinem Adressraum mussen ausschlieBlich im tmp- 
Nest eingetragen und zwischen-gepuffert werden, damit sie 
keine tatsachlichen Anderungen am orig-Eingang bewir- 
ken. 

30 Wovon der wichtigste meiner Ansicht nach die weitvehendc Vermei- 
dung von Verschnitt darstellt. 

31 Zur Nachbildung eines n-fachen Hardlinks muss dieser Baustein n- 
fach instantiiert werden, auBerdem muss noch eine Verwalturigslogik Ru- 
che Freigabe hinzukommen, die beispielsweise von einem gesonderten 
Verwaltungsbaustein erledigt werden kann. der sozusagen die „Aufsicht" 
iiberalle Namensanderungen und Verschiebungen aller beteiligten Namen 
Ubemimmt, Alternativ dazu kann dieser Baustein auch so ausgefiihrt wer- 
den, dass er n Steuer-Eingange hinzu-bekommt, die zusammen diese Auf- 
gabe Ubernehmen. 
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Die Implementierung vorT^rite-Transferoperationen 
bzw. get im Schreibmodus ist relativ einfach und folgt 
der bekannten Methodik, wobei Lbcher im Definitionsbe- 
re«ch von tmp direkt ausnutzbar sind. Schwieriger ist die 
Bereitstellung von move-Operationen. Eine Analyse dieses 
Teilproblems. ergibt, dass es starke Verwandtschaft mit der 
Adressverschiebungs-Problematik bei den map-Bausteinen 
besitzt. Eine mogliche Realisierung ist daher die interne 
Verwendung ernes map-Bausteins, der allerdings auch mit 
Lochern im orig-Nest korrekt umgehen konnen sollte. 

4.1.11 transaction 

Im Unterschied zu Datenbanken, wo Transaktions- 
Identifier (TIDs) meist fest mit Prozessen verkntipft sind 
verstehe ich unter einer Transaktion eine logische Sicht auf 
einen Datenbestand, die die bekannte ACID-Eigenschaft 
(Oder E.genschaften anderer Transaktions-Paradigmen) 
besitzt, und die von beliebig vielen Prozessen kooperativ 
(bzw. bei Verwendung zusatzlicher Sperren auch im 
multiuser- oder multiversion-Model!) nutzbar ist 
Durch die Aufgabe fester Zuordnungen zwischen Prozes- 
sen und DatenrSumen wird insbesondere auch ermdglicht 
dass ein Prozess an mehreren Transaktionen, auch parallel' 
teilnehmen darf. Das Standard-Szenario einer festen 11 
Zuordnung zwischen Prozessen und DatenrSumen ist als 
Spezialfall in diesem Modell enthalten. 

4.1.11.1 Sequentielle Transaktionen 
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Versions-Splits 32 entstehen, die dem Konzept einer einheit- 
hchen logischen Sicht widersprechen. 

Es ist klar, dass solche Ketten nicht beliebig lang wer- 
den durfen. Die Entfernung von Bausteinen ohne Anderuno 
der Semantik ist auf folgende Weise moglich: eine abaet 
schlossene Transaktion darf ohne weiteres invariante inter- 
ne Operationen ausfuhren, die von auBen durch die (°e- 
genuber cow neu hinzukommende) Operation integra- 
te angestoBen werden und bewirken, dass das Aus°an«»s- 
Nest weiterhin von auBen betrachtet denselben eingefrore- 
nen Zustand behalt, wahrend der Inhalt des tmp-Einoangs 
indasorig-Eingangsnestmte 5 r/ e rtwird,sodassdas tmp- 
Nest immer kleiner wird, bis es schlieBlich vollig leer 
wird. Bei dieser Integrations-Operation wird der Inhalt des 
orig-Eingangs so verandert. dass er schlieBlich mit dem 
eingefrorenen merged-Ausgang ubereinstimmt; damit ist 
die Isolation aufgehoben. Ab diesem Zeitpunkt darf man 
den nunmehr vSHig statuslos gewordenen transaction- 
Baustein aus der Kette entfernen, ohne dass sich Seitenef- 
fekte ergeben. 

4.1.11.2 Parallele Transaktionen 
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Ein cow-Baustein realisiert bereits einen wichtigen Teil der 
bekannten Isolations- FunktionalitOt von Transaktionen: urn 
eine Rollback-Operation zu simulieren, braucht man ledig- 
hch den Inhalt des tmp-Nestes zu vergessen und den mer- 
ged-Ausgang wieder auf den initialen Zustand des orig- 
Eingangs zu setzen. Ein transaction-Baustein laBt sich 
im Prmzip als leicht modifizierter cow-Baustein realisieren 
der seme grundsatzliche Funktionsweise von cow erbt. 

Die Commit-Operation laBt sich prinzipiell dadurch rea- 
lisieren, dass man einfach gar nichts tut: man hort auf 
Anderungen am merged-Ausgang vorzunehmen, und be- 
trachtet seinen Zustand als „eingefroren". Ein derartig ein- 
gefrorenes" Nest dient nun insbesondere als Ausgangs- 
punkt fur eine zeitlich nachfolgende(nicht-parallele)Trans- 
aktion, deren orig-Eingang mit dem merged-Ausgang 
der jeweils letzten erfolgreich abgeschlossenen Transakti- 
on verbunden wird, so dass im Endeffekt lange Ketten ent- 
stehen, die alle historischen Zwischenschritte der von den 
Transaktions-Operationen ausgelosten Zustande des Nestes 
reprasentieren. Der Ausgang der letzten erfolgreich abge- 
schlossenen transaction-Instanz einer Kette wird Ak- 
tualversion genannt. Hinter der Aktualversion darf vorlau- 
fig nur eine einzige, noch nicht abgeschlossene Transakti- 
on angeschlossen werden; ansonsten kSnnten divergierende 



Mit der soeben vorgestellten Methodik lassen sich nur rein 
sequential nacheinander ablaufende Transaktionen model- 
lieren. 

Zur Herstellung echter Parallelitat zwischen mehreren 
transaction-Instanzen miissen diese unbedingtan der- 
selben Aktualitatsversion angeschlossen werden (sofern sie 
nicht absichtlich mit einem veralteten Zustand beginnen 
wollen). Wenn man dies mit getrennten Einzel-Bausteinen 
fur jede Transaktion realisieren wiirde, dann miissten sich 
die verschiedenen Transaktions-Sichten iiber diesen oder 
einen anderen Anschluss-Punkt auf dem aktuellen Stand 
halten und jede fur sich den aktuellen Status an ihrem Ein- 
gang nachvollziehen, was im Prinzip mSglich ware, aber 
eine Vervielfachung von immer gleichartigen Operationen 
an mehrere Stellen bewirken wiirde 33 . Urn diesen Aufwand 
zu sparen, ist es gunstiger, eine konventionelle Implemen- 
tierung von Transaktionen (siehe z.B. [GR93]), eventuell 
auch von verschiedenen Transaktions-Modellen (siehe z.B. 

32 HierfUr gibt es reizvolle Anwendungen, sofern Methoden zur Rein- 
tegration von Splits vorhanden sind. Beispiele fUr SpliK treten u a bei 
Versions-Verwaltungssystemen fiir Software-Quelltexte auf. 

-FOr besondere Anwendungen, beispielsweise extrem hoher Ausfallsi- 
cherheit. kdnnte diese Idee eventuell trotz ihrer hohen Kosten interessanl 
sein. 
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[Elmbe]) in einen Baustein zu verpacken, der einen internen 
zentralen Puffer fur die Verwaltung aller vorkommenden 
Versionen benutzt, und/oder dessen Eingang im multi- 
vers ion-Modus arbeitet (dann muss allerdings auch die 
restllche Infrastruktur des Systems mitspielen). 

Bei der Kombination von Transaktionen mit Schutz- 
bereichen kann das Baustein-Konzept mit Funktionali- 
taten aufwarten, die in konventionellen Betriebssystem- 
Implementierungen einen erheblichen Aufwand verursa- 
chen wiirden. Ein Beispiel ist das Exeption-Handling 
in konventionellen Laufzeitumgebungen. Dieses kann auf 
einen Fehler nur noch reagieren, ihn aber meist nicht repa- 
rieren, da es beim Auftreten des Fehlers bereits „zu spat" 
ist. Transaktionen bieten die Moglichkeit, auf fruhere Zu- 
stande von Adressraumen zuriickzusetzen und erneute Ver- 
suche zu starten, und zwar auch auf ganze Kollektionen 
und Konfigurationen von Adressriiumen (spekulative Aus- 
fUhrung). 

Sehr interessant durfte auch die Kombination von 
Transaktions-Bausteinen mit den nun folgenden Baustein- 
jrfHfc. S ein, die verteilte Systeme in Netzwerken ermog- 
Jund zwar je nach Einsatz-Stelle auf verschiedenen 
i einer Baustein-Hierarchie. 
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4.1.12 remote 
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Dieser Baustein implementiert das Client-Server- 
Paradigma. Ein Nest wird auf einem anderen Rechner 
so verfiigbar gemacht, dass seine Eigenschaften nicht von 
"okalen Nest unterscheidbar sind. 

^^^lealisierung des Netzwerk-Protokolls kann status- 
fl^WTlgen, wenn man eine buf f er-Instanz nachschaltet, 
die durch ihr Caching den Datenverkehr uber die interne 
Netzwerk-Verbindung in vielen Fallen reduziert und neben- 
bei die Latenzzeit vieler Operationen senkt. Bei einer sta- 
tuslosen Realisierung halt der Client-Teil keinerlei Status- 
Informationen Uber den Zustand des Nestes vor, sondern 
muss jede einzelne Operation an den Server durch reichen. 
Dies fuhrt zu einer hohen Einfachheit, Robustheit, Unab- 
hangigkeit und Absturzsicherheit. 

Fragen der Einbruchssicherheit in Netzwerke, Verschliis- 
selung, Authentifizierung usw. sind eine interne Angelegen- 
heit der Baustein-Implementierung; in dieser Arbeit wird 
hierauf nicht weiter eingegangen. 



4.1.13 mirror 
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Dieser Baustein realisiert das Konzept von Verteiltem Ge- 
meinsamen Speicher (distributed shared memory). 

Eine Baustein-Instanz von mirror darf sich uber meh- 
rere physikalisch getrennte Rechner erstrecken, die mitein- 
ander uber interne (nicht von auBen sichtbare) Kommunika- 
tionsmechanismen in Verbindung stehen (hierfur bietet sich 
insbesondere Gruppenkommunikation an). Die Verteilung 
der Baustein-Instanz uber mehrere Rechner wird im Bild 
durch gestrichelte Linien angedeutet. 

Ein- und Ausgange sind im Grundmodell paarweise in 
der gleichen Anzahl vorhanden. Die Ausgange stellen die- 
selbe Funktionalitat dar, wie sie in einem nicht- verteilen Sy- 
stem von der gemeinsamen Verdrahtung mehrerer Eingan- 
ge auf denselben Ausgang erfiillt wird: uberall herrschrdie 
gleiche logische Sicht, das Nest ist logisch betrachtet iden- 
tisch und ermoglicht Kooperation im multiuser- oder 
mu 1 1 i ver s i on-Model 1 . 

Diese knappe, aber vollstandige Funktionsbeschreibung 
laBt viele Moglichkeiten fur die Realisierung zu, die im 
Wesentlichen den bekannten Techniken aus der Literatur 
folgen kann (siehe z.B. [TSF90, Doe96, Esk96]). Was die 
Eingange enthalten, kann bei verschiedenen mirror^*- 
Typen stark voneinander abweichen. Ich werde zwei Ex- 
tremfalle kurz erlautern: 

Bei einer Realisierung namens mirror_replicate 
enthalten alle Eingange den gleichen Nest-Zustand wie die 
Ausgange. Jede an irgendeinem Ausgang ankommende An- 
derung wird sofort auf alle Eingange aller verteilten Teil- 
Instanzen durch gereicht. Bei parallelem Zugriff auf meh- 
reren Rechnern erfordert dies im Regelfall verteilte interne 
Synchronisationsoperationen, urn die Konsistenz jederzeit 
zu wahren. 

Das dadurch verursachte Problem relativ hoher Latenz- 
zeiten la8t sich durch rechner-lokales Nachschalten je einer 
buf f er-Instanz hinter die Ausgange in vielen Fallen ab- 
mildern; daher kann die interne Realisierung der Kommu- 
nikationsprotokolle weitgehend statuslos erfolgen. 

Eine andere Realisierung namens mir- 
ror_primarycopy besitzt nur einen einzigen Eingang, 
der einem ausgezeichneten Rechner fest zugeordnet ist und* 
stets dort verbleibt, auch wenn weitere Ausgange auf ande- 
ren Rechnern dynamisch hinzugefugt oder weggenommen 
werden. 

SchlieBlich mochte ich noch auf Mischformen zwischen 
den beiden Extremen der vollstandigen Replikation aller 
Daten und der replikationslosen Primarkopie hinweisen. 
Dazu gehoren Baustein-Varianten, die ihre Eingange nicht 
fur Replikate, sondern fur die Bereitstellung der Summe al- 
les vorhandenen Platzes zu verwenden (disjunkt verteilter 
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Speicher). Es ist prinzipiell rnoglich, einen Baustein rair- 
ror_general zu schaffen, der sowohl die Extremfal- 
le der vollstandigen RepHkation als auch der Primarkopie, 
als auch beliebige Mischformen mit teilweiser Replikation, 
als auch Mischformen mit disjunkt verteiltem Speicher ab- 
deckt. 

Zu erwahnen ist weiterhin, dass die RAID-Konzepte 
(Redundant Array of Inexpensive Disks, vgl. [CLG+93]) 
als Spezialfall von mirror mit einer je nach RAID-Level 
besonderen Art der Redundanz- Verteilung aufgefasst wer- 
den konnen: es wird lediglich auf eine Verteilung der Ein- 
und Ausgange auf verschiedene Rechner verzichtet. Eine 
effiziente Realisierung von mirror sollte sich daher dar- 
um bemiihen, dass lokale Replikation keinen merklichen 
Overhead zur Folge hat. Damit wurde es sich auch fur die 
Aufgabengebiete eignen, in denen bisher Software-RAID 
eingesetzt wird. 

Implementierungen von mirror sollten auf jeden Fall 
den Grundideen der Ausfallsicherheit hohe Aufmerksam- 
keit schenken und z.B. mit dem Fall einer Netzwerk- 
Partitionierung (vgl. [DGMS85]) sinnvoll umgehen kon- 
nen. Eine detaillierte Behandlung dieser Konzepte wurde 
den Rahmen dieser Arbeit sprengen. Es ware interessant zu 
ergrunden, inwieweit das Baustein-Konzept und einige der 
hier vorstellten Bausteine bei der internen Realisierung von 
mirror Vorteile bringen konnen. 

SchlieBlich ist zu erwahnen, dass sich die Funktionali- 
tat von Prozess-Migration (vgl. [Smi88]) als Spezialfall von 
verteilt ablaufenden Kontrollfliissen auf verteilten gemein- 
samen Schutzbereichen bzw. durch Wechseln von Kon- 
frollflussen auf andere Rechner unter Benutzung gespie- 
gelter Schutzbereiche darstellen lasst. Hierzu ist erforder- 
lich, dass die verwendeten mmu^-Bausteine multiu- 
ser-Verhalten implementieren 34 . 

Die Verteilung von Nestern ist auch zur Herstellung ver- 
teilter gemeinsamer Namensraume sehr nutzlich; mirror 
ist somit die wesentliche Grundlage fur ein verteiltes Be- 
triebssystem. 

4.1.14 pip© 
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sondern z.B. auch Puffer-Nester, die nicht in den Hauptspei- 
cher eines Kleinrechners passen wurden. 



4.2 Instantiierung von Bausteinen 

Zur Instantiierung der Bausteine wird irgendein Mechanis- 
mus benotigt. Dieser sollte auBerhalb oder oberhalb der ei- 
gentlichen Baustein-Hierarchie liegen, da es sich urn einen 
ubergeordneten Kontroll-Mechanismus handelt. Nach dem 
Grundsatz der Trennung in Mechanismen und Strategien 
sind folgende Teilbereiche zu verwenden: 

1. Der eigentliche Instantiierungs-Mechanismus (techni- 
sche Durchfiihrung der Instantiierung) 

2. Die logische Kontrolle, welche Instantiierung zu wel- 
chem Zeitpunkt und aus welchem Anlass ausgefuhrt 
werden soil 

Diese Trennung hat den Vorteil, dass insbesondere fur 
Punkt 2 mehrere verschiedene Verfahren gleichzeitig oder 
konkurrierend eingesetzt werden konnen. 

4.2.1 Der Mechanismus 

Fur die technische Durchfiihrung der Instantiierung schla- 
ge ich vor, einen Baustein namens control einzuset- 
zen, von dem es auf jedem Rechner beliebig viele Iri- 
stanzen geben kann, wobei im Normalfall jedoch eine In- 
stanz ausreicht, die ihrerseits beim Urstart auf eine Weise 
instantiiert worden sein muss, die ausserhalb des norma- 
len Instantiierungs-Mechanismus liegt (und logischer weise 
auch liegen muss 35 ). 

Der control-Baustein verwaltet. alle von ihm erzeug- 
ten Baustein-Instanzen samt Verdrahtung. Er selbst benotigt 
ebenfalls Betriebsmittel, beispielsweise den Maschinenco- 
de von sich selbst. 



tmp h^^h 








pipe 





participantl 
participant2 



code 
tmp 
inl 
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Zum Verstandnis des pipe-Entwurfs muss man sich 
nochmals in Erinnerung rufen, dass eine Leitung eine 
Hierarchie-Beziehung zwischen Baustein-Instanzen dar- 
stellt und nichts direkt mit Datenfluss-Richtungen zu tun 
hat. In abstrakter Sicht sind daher die Teilnehmer an einer 
Pipe prinzipiell gleichberechtigt, sie werden daher an ver- 
schiedenen Ausgangen angeschlossen. Der interne Status 
einer pipe-Instanz wird in einem tmp-Eingang gehalten, 
an den sich nicht nur d evice_ramdisk anschlieBen laBt,' 

-^WeJche Auswirkungen dies auf die Performanz haben kann ist ei- 
ne andere Frage. Im Prinzip haben wir damit eine NUMA-Architektur in 
Software realisiert. 




- — ■ control 



image 
outl 



out2 



Ich schlage vor, diese beiden Funktionsbereiche logisch 
zu trennen: Die von einer control-Instanz verwalteten 
Baustein-Instanzen konnen i.a. in einem anderen (virtu- 
el Ien) Adressraum (der wiederum in Sphutzbereiche auf- 
geteilt sein kann) liegen als die control-Instanz selbst; 
damit sind z.B. beliebige hierarchische Schachtelungen 

35 Nach dem Urstart mQssen bereits Bausteine vorhanden sein, damit das 
System in Betrieb gehen kann (unverzichtbare Geriitetreiber und Aquiva- 
lent eines Root-Dateisystems). 
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. von Adressraumen Oder ganzen virtuelSfT Maschinen mog- 
hch . Die steuernde control-Instanz bedient sich des 
tmp-Eingangs, urn darin den gesamten notwendigen Sta- 
tus zu halten, und stellt am image-Ausgang efn Pro- 
zessabbild" bzw. eine Menge von Schutzbereichen zur 
Verfugung, die in einer nachfolgenden (ggf. aber Zwi- 
schenbausteine wie union angeschlossene) mmu_i386 
Oder mmu_dunimy-Instanz zur eigentlichen Ausfiihrung ge- 
bracht werden. Damit ist eine Separation zwischen dem 
Adressraum moglich, der die control-Instanz beher- 
bergt, und dem Adressraum, in dem die verwalteten Instan- 
zen laufen sollen. Durch diese Trennung ist es u.a. moglich 
Teile eines Betriebssystems in „Benutzer"-Adressraumen 
ablaufen zu lassen. Benutzer konnen auf diese Weise von- 
einander unabhangige Subsysteme schaffen, die von der 
Funktionalitat her virtuellen Betriebssystemen gleich kom- 
men. Damit verschwimmt die klassische Einteilung in 
Kern- und Benutzer-Zustandigkeiten; die Verteilung dleser 
Zustandigkeiten ist nur noch eine Frage der Konfiguration. 

Eine Trennung zwischen der control-Instanz und ih- 
Jj^irnage in separate Adressraume ist jedoch keine 
M m : wenn man den image-Ausgang in die gleiche 
mjjp*-Instanz einblendet, in der auch der control- 
^^tein beheimatet ist, kann man ohne weiteres Sin°le- 
Address-Space-Strategien 38 fahren. Als weiterer Sonderfall 
ist es pnnzipiell auch moglich, dass ein control-Baustein 
sich selbst verwaltet 39 ; in diesem Fall besteht kein Unter- 
schied zwischen „innen" und „auBen"; eine Destruktion der 
control-Instanz wurde dann nicht nur zur Destruktion al- 
ler verwalteten Instanzen fuhren, sondern nie mehreine er- 
neute Re-Konstruktion ermoglichen (dies kann ausnahms- 

*Diese Trennung bewirkt u.a., dass sich die Abstraktionen Nest und 
Bauste.n .n un.former Weise auch in konventionellen ..Benutzerprois- 
sen verwenden lassen. eventuell sogar in sogenannten ..Anwendungs- 
Programmen • - es besteht Uberhaupt kein prinzipiel.er Unterschied zw - 
schen ..Kern - und ..Benutzer"-Ad res .sraumen bzw. -Schutzbereichen 

• Im Extremfall kann das gesamte Betriebssystem in einem einzigen 
Adressraum ablaufen, was z.B. bei Echtzeit-Steuerungen PerformTz- 
Vorte.le bnngt. Falls Schutzbereiche genutzt werden. laB, sich « 
em brauchbarer Zugnffsschutz realisieren (vgl. [C+94D Im UnterschieH 
^nnten Architeka.ren (vgl. fK+97]) Irlaubt die 7& vorgSe 
Hsmoglichkeit beliebige Zwischenstufen zwischen reinen Single- 
Ipace-Modellen und vollkommener Aufplitterung aller Funktio- 
weils getrennte mmu_Mnstanzen. 
Die Benutzung eines einzigen virtuellen Adressraums im gesam- 
en System laBt sich dadurch modellieren. daB nur eine einzige mmu *- 
Instanz vorhanden ist. in der das gesamte System ablauft. Obwohl die- 
rr+fT p" ofl ^ 1 h ° he Aufmerks ^keit in der Literatur erhalten 
hat [C+94 Ros94. As.s96], S ehe ich darin keinen grundlegenden Vorteil 
Die Umschnltung emer Standard-MMU auf verschiedene Schutzbereiche 
kastet (m.t wenigen Ausnahmen) im Worst Case greBenordnungsmaBig 
ebenso ve w.e d.e Umschaltung zwischen verschiedenen Adressraumen 
led.gl.cn der Best Case geht u.U. effizienter. In welcher Groflenordnung 
sich dieser m 8gllche Performanz-Gewinn auf das Gesamtsystem auswirkf 
, " V , °, B ^ f iCher Gr8Ben °«">»"g n^ht auch durch andere 2 
tekturelle M^nahmen erzielbar sind. sind genauer zu untersuchende Fra- 
gen Memer Aas.chtnach stellt die Einengung auf ein/ e .«e, Single-Space- 
Modell erne Emschriinkung dar. die mil der hier vorgestellten Arehitektur 
aufgebrochen werden kann. 
w Die einfachste Losung hierfilr besteht darin. dass der tmp-Bingang 
de fi r "U^'nstantiierung" das richtige Prozessabbild mit der 
Bauste.n-Konngurat.on enthalt. mit dem zu starten ist. Wenn dieses auch 

v^rw S n C °H ntr c 0l - |nS,anZ enthiUt - en,StCht automatisch die SetbM- 
verwaltung Be. der Systemgenerierung eines bootfahigen Systems wird 
auf emem (fremdea) Rechner ein entsprechendes ProzessabbUd Z a^en 
zum Urstart notwendigen Instanzen ers.ellt; dieses kann dann mit konven- 
t.onellen Ladern analog wie klassische Unix-Kerne geladen warden 
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weise beim Herunterfahren des Rechners auch erwunscht 

Die Befehle zum Instantiieren / De-Instantiieren der ver- 
walteten Instanzen sowie zum Verdrahten werden iiber den 
control-Ausgang gegeben. Eine Moglichkeit ist die Ein- 
fuhrung weiterer Elementar-Operationen, oder die Benut- 
zung der Schnittstelle von generischen Operationen (Kapi- 
tel 6). Da auf dieser Leitung nur Steuer-Operationen benutzt 
werden, ,st sie gestrichelt gezeichnet. Uber den control- 
Ausgang lassen sich fernerhin die Attribute der instantiier- 
t ^.,?f USt !^ e, Ein " Und Aus SSnge und die Verdrahtungs- 
Straktur abfragen. Auftraggeber fur diese Operationen k6n- 
nen beliebige Bausteine sein; i.A. diirfen diese auch in 
image liegen 4 ". Zu Zwecken der Kommunikation nach au- 
Ken existiert eine dynamische Anzahl von Ein- und Aus- 
gangen in* und out*"', die als SchnittsteUen mr LRpc 
dienen und die zu beliebigen Zwecken einsetzbar sind 42 

Es ist sinnvoll, das Instantiieren / De-Instantiieren vom 
Konstruieren / Destruieren zu trennen: Beim Instantiieren 
wird ledighch Platz fQr die Baustein-Infrastruktur (z B sta- 
tische Attribute) angelegt und die Verdrahtung ermoglicht 
Die Parametrierung der Baustein-Instanz (z.B. Festlegen 
dynamischer Attribute) erfolgt spatestens beim Konstruie- 
ren. Wenn man einen Baustein nur destruiert, aber nicht de- 
instantuert, wird er im Endeffekt lediglich in den Zustand 
der Statuslosigkeit geschaltet (d.h. nach dem Abarbeiten al- 
ler evtl. noch vorliegenden AuftrMge wird derevtl. noch vor- 
handene interne Status auf die Eingange abgewalzt, danach 
werden keine Operationen mehr bearbeitet), und er kann an- 
schhessend durch Konstruieren wieder in Betrieb genom- 
men werden. 

Details zur internen Realisierung von control werden 
in d.eser Arbeit nicht behandelt; die grundlegende Funkti- 
onsweise soil hier nur skizziert werden: 

Im code-Eingang wird dynamisch linkbarer Maschinen- 
code fur alle instantiierbaren Baustein-Typen bereitgehal- 
ten . Bei der erstmaligen Verwendung wird er nach tmp 
kop.ert und dabei gelinkt. Die Instanzen der verwalteten 
Bausteine werden in zwei Phasen erzeugt: aus den stati- 
schen Attributen des zu instantiierden Baustein-Typs wird 
der Speicherplatzb edarf fUr eine Instanz ausgelesen und 

^Hierbei kann es i.A. zu Pmblemen mit RekunUm konunen, wenn der- 
T f'J'^ber sich seibs, betreffende Openuionen in AufiragX, 
"Alternanv zu diesen Ein- und Augangen kdnnte man auch LRPC- 
Vananten von remote benutzen; damit muBten keine Verdrahtungsleitun- 
gen zwschen Kommunikationskanfilen auf demselben Rechner veSet 
werden M.r scheint jedoch die explizite Verwaltung von Leitu"genTreh 
erne Obergeordnete Instanz sicherer zu sein. da eine Lehung ^£ 2 
ne rud.ment a re Form von Authentifizierung berei, stellt. die Li Sne- 
ter Abschottung der Subsysteme (z.B. Partitionierung in Schutzbere f he) 

m° a X^nT en T" li8en r ,0giSChe " Su P--or"einbruch^cter ge- 
~ h *t^°' ^ Z " aufweni S ere " Massnahmen wie VerschlUsse- 
lung beim LRPC gre.fen zu mUssen. 

«Dies ist nicht nur zur Herstellung mehrerer virtueller Rechner- 
Paruuonen mteressant oder zu deren Kommunikation ilbe gLeta 
Daten w.e Dattisysteme". sondern beispiekweise auch zum Checkpoint 
/ Restart einer einzigen Betriebssystem-Instanz. wenn n^rbeispielswei 
se vor tmp eine transaction-Instanz vorschaltet. Eine weUere An- 
wendung ware bei.spielswei.se das Vorhalten eines kompletten Ersatz 
Betnebssystem-Abbildes. das bei Stdrungen einspringen kann 

raair^^^^ 
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entsprechender Platz in tmp reserviert. AnschlieBend wird 
eine Instantiierungs-Routineaufgerufen; diese kann bei Be- 
darf weitere Aktionen ausfuhren 44 . Nach der Instantiie- 
rung sollte im Regelfall die Verdrahtung stattfinden; hierbei 
kann bereits auf Konflikte zwischen statischen Kompetenz- 
Attributen und Verhaltens-Attributen gepriift werden. Die 
Konstruktion erfolgt ebenfalls durch Aufruf einer baustein- 
spezifischen Routine mit passenden Parameters Da u.U. 
erst zu diesem Zeitpunkt dynamische Attribute festgelegt 
werden, kann die Konstruktion auch fehlschlagen. Destruk- 
tion und De-Instantiierung funktionieren analog. 

4.2.2 Einige mogliche grundlegende Strategi- 
en 

Bei den Anldssen fur eine Instantiierung sind mehrere mog- 
liche Szenarien zu unterscheiden: 

1. Manche Baustein-Arten wie z.B. dir_* konnen nur 
an bestimmten vorgegebenen oder vorgebbaren Stel- 
len einer Baustein-Hierachie instantiiert werden, weil 
sie einen Interpreter fur ein bestimmtes konkretes Da- 
tenformat darstellen. Es macht i.a. keinen Sinn, ande- 
re Baustein-Arten als die fur die jeweilige Interpretati- 
on geeigneten zu instantiieren; haufig existiert fur ein 
bestimmtes Datenformat nur eine einzige Interpreter- 
Baustein-Art (in einem gewachsenen System aller- 
dings oft in verschiedenen Versionen, von denen bei 
der Instantiierung die geeignete ausgewahlt werden 
muss). ' 

2. Andere Baustein-Arten wie z.B. mmu_* oder ge- 
schachtelte control-Instanzfen werden fast aus- 
schlieBlich auf Veranlassung von Benutzer-Aktivitaten 
instantiiert. 

3. Es gibt Mischformen zwischen beiden Extremen: ein 
Verzeichnis-Pfadname wird zwar vom Benutzer vorge- 
geben, die Art des jeweils zu inantiierenden Bausteins 
hangt jedoch vom Datenformat ab. 

4. In manchen Fallen k6nnen Instantiierungen oder Re- 
Instantiierungen auch ohne konkreten aufieren Anlass 
geschehen, z.B. zeitgesteuert in selbsttatig optimieren- 
den Betriebssystemen (vgl. [BR76]) oder zur Erzie- 
lung von Fehlertoleranz und Ausfallsicherheit. 

Der Fall 1 laBt sich entweder direkt in control abhan- 
deln, oder durch einen eigenen Baustein-Typ registrar, 
der als Registrar fur verschiedene Datenformate dient. Da- 
tenformatesollten vorzugsweise im zugehorigen Meta-Nest 
beschrieben werden; es gibt aber auch auch Sonderfalle wie 
Platten-Partitionen oder dir_*-Bausteine fur konventio- 
nelle Archiv-Datei Formate (wie . tar oder . zip), bei 
denen die Format-Erkennung durch Inspektion des Inhal- 
tes des betreffenden Nestes erfolgen muss. Ein Registrar 

44 Bei sicherheitskritischen Anwendungen kann die AusfUhrung von 
Instantiierungs- und Konstruktor-Routinen durch die control-Instanz 
eine Gefahrdung darstellen, insbesondere wenn den in der nachgeschal- 
teten mmu_*-Instanz ablaufenden Aktivitaten oder dem Inhalt von code 
nicht zu trauen ist. In diesem Fall sollte der Aufruf durch LRPC stattfinden 
und im Kontext der nachgeschaltenen mmu_* ausgefQhrt werden. 
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verwaltet daher auch die Methoden fur die automatische 
Format-Erkennung. 



inl 
in2 




- - j registrar j- - - - | 



scraregy^x 
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Um eine moglichst hohe Flexibilitat bei verschiedenen Aus- 
losern von Instantiierungen zu erreichen, schlage ich die 
Einrichtung von s trategy_* -Bausteinen vor. Diese steu- 
ern den control- oder regis trar-Baustein und erhal- 
ten von dort Informationen uber vorhandene Datenforma- 
te und Kompetenzen; sie werden ihrerseits von anderen 
Steuer-Instanzen wie z.B. Benutzer-Operationen oder an- 
dere strategy_*-Instanzen gesteuert. Im Bild sind die 
Steuerleitungen gestrichelt gezeichnet. 

Ein Beispiel ware ein Baustein strat- 
egy_asciipath, der Pfadnamen in ASCII-Codierung 
akzeptiert und indirekt uber registrar bzw. con- 
trol auf einen Verzeichnisbaum von dir_*-Instanzen 
abbildet. Ein weiterer Baustein strategy_utf_ascii 
Hesse sich zwischenschalten, um Pfadkomponenten in 
Unicode- oder UTF-8-Codierung nach ASCII zu uberset- 
zen und dabei UTF-8-Sonderzeichen in eine umkehrbar 
eindeutige aquivalente Mehrzeichen-ASCn-Reprasentation 
zu ubertragen. Ein weiteres Beispiel ware strat- 
egy_ascii_bin, der binar kodierte Zahlen-Schliissel 
(z.B. Feldschlussel in Datenbanken) aus aquivalenten 
ASCII-Reprasentationen erzeugt. Weitere strategy_*- 
Arten konnten z.B. die Verwaltung von URLs ubernehmen; 
der Erweiterbarkeit und Flexibilitat werden durch diese Ar- 
chitektur kaum Grenzen gesetzt. Um standig wiederholende 
Instantiierungen / De-Instantiierungen von Bausteinen zu 
verhindern, kann strategic ache einen „Vorrat" von 
haufig benutzten Instanzen anlegen, die bei Nichtbenutzen 
evtl. lediglich auf „statuslos" geschaltet werden. Die 
Funktionalitat des klassischen f ork-Systemaufrufs von 
Unix lasst sich ebenfalls durch strategy_*-Bausteine, 
diejenige von /proc-Dateisytemen durch spezialisierte 
Arten von Registraren herstellen, die fur automatische 
Default-Instantiierungen registrierter Komponenten sorgen. 

Das Problem von inkompatiblen Kompetenzen und Ver- 
halten von versuchten Baustein-Verdrahtungen bzw. Kon- 
struktionen lafit sich durch einen zwischengeschalteten 
regis trar_intermediate losen. Dieser kennt al- 
le moglichen adaptor.* und sonstigen Konversions- 
Baustein-T/pen samt ihren Eigenschaften und veran- 
lasst bei Bedarf die automatische Zwischenschaltung 
der geeigneten Komponenten. Auf ahnliche Weise laBt 
sich Netzwerk-Transparenz durch automatisierte Zwischen- 
schaltung von remote erzielen. 

Bei Implementierung geeigneter Strategien (z.B. 
[LS94]) lasst sich Fehlertoleranz durch automatisches Re- 
Instantiieren von ausgefallenen Bausteinen erzielen, oder 
in Kombination mit der Netzwerk-Transparenz zur dynami- 
schen Lastbalancierung nutzen. Es sind unzahlige weitere 
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Anwendungen fur strategy,* und registrar,* 
denkbar. 

Fur Datenbank-Konstrukteure konnte eine reizvolle Auf- 
gabe darin bestehen, einen Baustein strategy_sql zu 
entwickeln, der sich bei geeigneter Auslegung nicht nur 
fur die klassischen Einsatzgebiete in Datenbanken eignet 45 , 
sondern das Prinzip der Trennung von logischen und phy- 
sischen Zugriffspfaden auch auf solche Einsatzgebiete aus- 
dehnt, die bisher als Dornane von Betriebssystemen 46 oder 
verteilten Systemen betrachtet wurden (insbesondere das 
Management virtueller Benutzer-Adressraume 47 ). 




45 Durch zwischen geschaltete remote-Bausteine durften sich auch bei 
den klassischen Einsatzgebieten von Datenbanken neue Konfiguations- 
moglichkeiten ergeben, die bei bisherigen Datenbank-Architekturen nicht 
einfach zu realisieren waren. Zu nennen ist hier insbesondere die Einbezie- 
hung des Verhaltens von Flaschenhalsen wie remote-Instanzen in rech- 
neriibergreifende Query-Optimierungs-Strategien; es kann beispielsweise 
in manchen Szenarien durchaus vorteilhaft sein, Tabellen erst mittels re- 
mote auf Client-Rechner zu exportieren und dort mittels buffer zu ca- 
chen, bevor umfangreiche Joins oder andere Produkte daraus hergestellt 
werden. 

46 Durch derartige Verbindungen konnte man beispielsweise Pfadnamen 
durch SQL-Abfragen ersetzen. 

47 Dieser Ansatz geht uber die Integration von Dateien in Datenban- 
ken (vgl. [HR01, Abschnitt 3.5]) weit hinaus, da man sowohl Dateien 
als auch Datenbank-DatensStze jeweils sowohl Uber SQL als auch uber 
Verzeichnis-Pfade zugreifbar machen kann; bei dieser Stufe der Integrati- 
on verschwimmen die konventionellen Unterschiede zwischen Datenban- 
ken und Betriebssystemen vflllig. 
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Callbacks durch not if y-Operationen 



Hierarchische Beziehungen driicken ein Abhangigkeitsver- 
haltnis aus. Baustein-Instanzen, die „hoher" in einer Hier- 
archie stehen, haben „Macht" 0 der „Kontrolle" iiber sol- 
che, die weiter unten stehen. Die Leitungen des Baustein- 
Modells drucken derartige Hierarchie-Beziehungen aus. 

Es gibt jedoch Falle, in deiien sich eine eindeutige Hierar- 
chie nicht immer reinrassig ausfuhren IaBt. Betriebssystem- 
Konstrukteure versuchen traditionell, solche Falle mog- 
lichst zu vermeiden. Im Idealfall sollte ein Betriebssystem 
durch ein Schichtenmodell beschreibbar sein (vgl. [Dij71]). 
Die notify-Operationen sind dazu gedacht, um ein 
Schichtenmodell auch dann noch beibehalten zu konnen, 
wenn es aus irgendwelchen Grunden klemmen wurde (vgl! 
[CIa85]). In dieser Sichtweise haben notify-Operationen 
einen Ausnahmecharakter, der nicht missbraucht werden 
sollte. Ich werde versuchen, diejenigen Anwendungsfalle 
zu begrunden, in denen ich Vorteile durch den Einsatz von 
notify-Operationen sehe. 

i 

5.1 Eigentums- und Besitzverhaltnis- 

se 

Die Begriffe Eigentum und Besitz stammen aus dem 
Rechtswesen. Dort kennzeichnen sie den Erstreckungsbe- 
reich eines Rechtes: wer Eigentiimer einer Sache ist, der 
hat weitergehende Rechte als der Besitzer. Es ist insbeson- 
dere moglich, Sachen auszuleihen oder zu vermieten; da- 
bei bleibt man weiterhin Eigentumer, obwohl der Besitzer 
(kurzzeitig) wechselt. Der neue Besitzer kann transitiven 
Unterbesitz an einer Sache oder Teilsache an ein Oder meh- 
rere Unterbesitzer weitergeben; diese schulden die Riick- 
gabe an den Hauptbesitzer, das ist derjenige, von dem sie 
den Unterbesitz erhalten haben; dieser schuldet wiederum 
die Riickgabe des Besitzes an den Eigentumer. Der Eigen- 
tiimer ist jemand, der niemandem die Riickgabe des Besit- 
zes schuldet 1 . Im realen Leben kommen solche Rechtsver- 
haltnisse z.B. bei der Vermietung und Untervermietung von 
Wohneigentum vor. Ein Mieter einer 5-Zimmerwohnung 
kann z.B. jedes Zimmereinzeln an Studenten untervermie- 
ten. 

Diese Analogie mochte ich zur Darstellung der Verhalt- 
nisse in einem Betriebssystem einsetzen; dabei werde ich 
als Beispiel das Eigentum und den Besitz an Datenblocken 
und an Locks nehmen; diese Methodik ist auch auf andere 

1 Die einzige Ausnahme ist der Tod eines Eigentiimers. 



Objekte ubertragbar. 

Eigentums- und Besitzverhaltnisse sind von einer Hierar- 
chie unabhangig 2 und konnen sich dynamisch zur Laufzeit 
andern. Eine Baustein-Hierarchie teilt die Gesamtverant- 
wortung eines Betriebssystems in statische Zustandigkeiten 
auf; bei der ttbertragung eines Besitzes wird dagegen die 
temporare Verantwortung fiir die zu verwaltenden Objekte 
innerhalb der Hierarchie weitergegeben. 

Bei physischen Datenblocken gibt es einen naturlichen 
Eigentumer: das ist diejenige Instanz, die die physische 
Adresse festlegt und verwaltet, z.B. indem sie den Daten- 
block „erzeugt'\ d.h. in Existenz bringt 3 . In der Regel stellt 
dieser naturliche Eigentumer den Datenblock her, um ihn 
anschlieBend zu „verleihen", d.h. das Zugriffs- oder Besitz- 
recht an eine andere Instanz fur eine bestimmte Zeit abzu- 
treten. Der neue Besitzer kann hierarchisch tiefer oder ho- 
lier stehen. Unabhangig von der Hierarchie aber muB er den 
Besitz irgendwann wieder an den Eigentumer zuruckgeben, 
ansonsten droht das bekannte Problem der Ressourcenver- 
knappung durch nicht mehr recycelbare Ressourcen. Das 
folgende Bild zeigt einen Ausschnitt aus einem Szenario 
eines Rechners, der mit MMU-Hardware ausgestattet ist: 



• • • 

• • • 



■■■ j' ronu_l386 | 
j ronu_1386 | 



■ j mmu_i366 j 



Prinzipiell kommt als Eigentumer oder Hauptbesitzer von 
Datenblocken jede der beteiligten Baustein-Arten in Fra- 
ge. Es bringt jedoch Vorteile, wenn die Adressvergabe der 
physischen Datenblocke von der Adressvergabe im jewei- 
Iigen logischen Adressraum getrennt wird. Bei den logi- 
schen Adressen gibt es einen notwendigen Eigentumer bzw. 
Hauptbesitzer, der daruber zumindest in den Grundzugen 
bestimmen konnen muss: das ist der Benutzer, der ganz 
hinten als Endkonsument sitzt und bestimmen mochte, was 

2 BeispieIsweise kann auch in einer absoluten Monarchie ein Untertan 
Eigentum erwerben, auf das der K5nig keinen Zugriff hat Wenn dies nicht 
mflglich ware, mUssten die Untertanen verhungefn, da sie ohne Zustim- 
mung des KOnigs kein Eigentum und keinen Besitz an Lebensmitteln er- 
werben kdnnten, auch nicht an solchen Lebensmitteln, die sie selbst her- 
gestellt haben. 

3 Beim Start des Betriebssystems gehan sSmtlicher Speicher einem 
Urbesitzer, der ihn dann an andere Instanzen wie Caches oder devi- 
ce_ramdisk „aus!eiht". 
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der Rechner und das Betriebssystem raFihn tun soil; er 
kann zwar einige dieser Aufgaben an den Compiler oder 
das Laufzeitsystem (Benutzer-Heap-Verwaltung) delegie- 
ren, aber letztlich ist er der Herr uber seinen virtuellen 
Adressraum. 

Physische Adressen lassen sich prinzipiell sowohl ganz 
oben bei den Tnmu_* -Instanzen als auch ganz unten bei 
der buf f er-Instanz bzw. der evtl. vorgeschalteten devi- 
ce_mem-Instanz verwalten. Bei Vorhandensein von MMU- 
Hardware ist es jedoch aus mehreren Griinden vorteilhaft, 
die Verwaltung phyischer Adressen und damit das Eigen- 
tumsrecht der buffer- bzw. device^mem-Instanz und 
nicht den vielen inmu-Instanzen zu ubertragen: 

• Verschiedene ramu-Instanzen greifen haufig auf die- 
selben Datenblocke zu; beispielsweise gemeinsamer 
Maschinencode. Wenn das Eigentumsrecht bei der 
buf f er-Instanz liegt, ist die gemeinsame Nutzung 
von Datenblocken relativ einfach zu realisieren. Bil- 
Hgt man das Eigentum dagegen den mmu-Instanzen zu, 

I dann findet entweder keine gemeinsame Nutzung statt, 
**^r diese muss wesentlich aufwendiger z.B. uber 
'Cache-Koharenz-Protokoll hergestellt werden, das 
:h uber die gesamte Hierarchie hinweg erstrecken 
kann. 

• Die Gefahr von Deadlocks ist leichter vermeidbar, da 
eine zentrale Instanz besser die Ubersicht uber die ver- 
gebenen Ressourcen wie Locks behalten kann. 

Im folgenden Beispiel ist keine MMU-Hardware vorhan- 
den. Die Verwaltung der physischen Datenblock- Adressen 
muss(\) wegen der notwendigen Ubereinstimmung von lo- 
gischen und physischen Adressen bei den rranu_dummy- 
Instanzen erfolgen, die als Ersatz fur die fehlende MMU- 
Hardware stehen: 





Wenn keine MMU vorhanden ist, dann ist eine unabhan- 
gige Ubersetzung von logischen Adressen nach physischen 
Adressen nicht moglich; es bleibt als einzige Losung, die 
physischen Adressen mit den logischen Adressen gleich- 
zusetzen. Daher ist es gunstiger, das Eigentumsrecht zu- 
mindest an denjenigen Datenblocken, die in Prozessab- 
bildern verwendet werden, ganz oben in der Hierarchie 
bei rnmu_dummy oder process_manager zu verwal- 
ten (andernfalls konnten keine Transform ationen durch da- 
zwischenliegende dir_*-Instanzen durchgefuhrt werden, 
oder es mussten zusatzliche Performanz fressende Kopien 
erstellt werden 4 ). 



Wenn man Kopien herstellt, dann betreibt man Ietzlich eine Misch- 
formderZuordnung von Eigentumsrechten an verschiedene Instanzen. Die 
..Originate" werden unten in der Hierarchie verwaltet (siehe MMU-freies 
Ur-Unix mit Buffer-Cache in [Lio96]), die Kopien entstehen dann implizit 
z.B. bei read- oder write-Operationen. 



Diese Erorterung sollte bewusst gemacht haben, dass 
Eigentums- und Besitzverhaltnisse prinzipiell unabhangig 
von Hierarchie-Beziehungen sind, und dass eine gut durch- 
dachte Zuordnung Implementierungs- Auf wand und Perfor- 
manz sparen kann. 

Die in Abschnitt 3.1 eingefuhrte Unterscheidung zwi- 
schen logischem und physischem IO auf Nestern korre- 
spondiert mit dem Konzept der Eigentums- und Besitzver- 
haltnisse in folgender Weise: 

• Ein Eigentumer bzw Hauptbesitzer bietet stets lo- 
gischen IO an seinem Ausgang an. Die hoheren 
Hierarchte-Instanzen sind gezwungen, logischen IO zu 
verwenden, wenn sie in den (temporaren) Besitz eines 
Datenblocks gelangen wollen; der in Abschnitt 3.3.3 
eingefuhrte Referenzzahler dient zur Verwaltung der 
„AusIeih-Rechtsverhaltnisse"; im juristischen Kontext 
wurde man dies als „Schuldverhaltnis" charakterisie- 
ren. Ein „Schuldner" muss irgendwann seine „Schul- 
den" wieder „zuruckzahlen"; dies geschieht in der hier 
vorgestellten Archtektur durch korrekte Paarung von 
put. 

• Ein Eigentumer betreibt an seinem Eingang aus- 
schlieBIich physischen IO; die unterliegenden Instan- 
zen brauchen nur diese Betriebsart zu unterstiitzen. 

Es ist jedoch sinnvoll, dass zwischenliegende Instanzen wie 
dir_* sowohl die Kompetenzen zu logischem als auch zu 
physischem IO haben sollten. Dies ermoglicht nicht nur den 
Einsatz der neuen Architektur in MMU-freier Hardware 
wie embedded systems, sondern rein theoretisch sogar den 
gemischten Einsatz von solchen Prozessen, die in virtuel- 
len Adressraumen laufen, neben MMU-ubersetzungsfreien 
Prozessen 5 . 



5.2 Riickforderung von Eigentum 

Wie im realen Leben kann es auch in einem Betriebssy- 
stem vorkommen, dass ein „Schuldher" seine „Schulden" 
nicht bezahlt, oder nicht „rechtzeitig" bezahlt. Die Einfuh- 
rung eines ,Jvlahnwesens" ist prinzipiell geeignet, den Sy- 
stemdurchsatz zu verbessern oder in hoffnungslosen Man- 
gelsituationen Oberhaupt noch ein Weiterarbeiten zu ermog- 
lichen. ° 

notify_data (nest , log_addr , len, 

phys^addr, urgency) ~> success 
notify_lock (nest , log_addr, len, 

try_address , try_len, 
kind, urgency) ^ success 
Diese Operationen durchlaufen eine Baustein -Hierarchie in 
umgekehrter Richtung, d.h. vom Eigentumer hin zu den 
Konsumenten. Die Konsumenten werden gebeten oder ge- 
zwungen, die jeweilige Ressource (ein Datenblock mit der 
angegebenen logischen und physischen Adresse, oder ein 

5 Wieviel Sinn dies macht, ist eine andere Frage. Theoretisch kann 
em MMU-freier Prozess schneller laufen. da der Hardware-Aufwand zur 
AdressUbersetzung wegrailt, und garantiert keine Verzogerungen durch 
Seitenfehler-Unterbrechungen auftreten. Utzterer Effekt wird in echtzeit- 
ffihigen Betriebssystemen jedoch auch durch vorgeladene und nicht ausla- 
gerbare Speicherseiten erzielt. 



ask 



try 



5.2. ROCKFORDERUNG VONEIGENTUM 

■ A 

Lock der angegebenen Art) zurBckzugeben. Der Parameter 
urgency kann einen der folgenden Werte annehmen: 

Es wird lediglich angefragt, ob eine Riickgabe 
der Ressource ohne groBere Miihen und Sto- 
rung des Betriebes moglich ware. Der Emp- 
fanger brauchtauBer der boolschen success- 
Riickmeldung nichts zu unternehmen. 

Der Empfanger wird gebeten, die Ressource 
zuriickzugeben, wenn es den Betrieb nicht un- 
verhaltnismaBig stort. Ein genauer Zeitpunkt 
fur die Riickgabe wird nicht vorgeschrieben. 

command Der Empfanger wird aufgefordert, die Riickga- 
be unverzuglich (d.h. noch vor der success- 
Ruckmeldung) vorzunehmen. Eine Verweige- 
rung der Riickgabe durch Rucklieferung von 
success=f alse ist nurdann statthaft, wenn 
der Empfanger wegen der fehlenden Ressource 
seine Tatigkeit ganz einstellen miisste. 

force Der Empfanger muss die Ressource unverzug- 
lich zuriickgeben, auch wenn er dadurch zum 
Abbruch seiner Tatigkeit gezwungen- wird. 
Falls er sich dennoch weigern sollte 6 , werden 
alie seine Ressourcen „konfisziert", d.h. vom 
Eigentumer so behandelt, als waren sie zuruck- 
gegeben worden, und es finden im Zukunft 
keine Operations- Ausfuhrungen mehr statt, die 
durch die Empfanger-Instanz in Auftrag gege- 
ben worden sind oder noch gegeben werden. 

Die notify_*-Operationen haben den Charakter einer 
Ausnalvne und sind konzeptuell mit'den Signalen von Un- 
ix und anderen Betriebssystemen vergleichbar. Prinzipiell 
sind daher Wettrennen zwischen notify_*-Operationen 
und Anforderungs- bzw. Riickgabe-Operationen des Besit- 
zers moglich. Diese Wettrennen treten auch bei vergleich- 
baren Situationen in konventionellen Betriebssystemen auf 
und sind meiner Ansicht nach prinzipbedingt (siehe Dis- 
kussion in Anhang C). Wettrennen lassen sich zwar durch 
architekturelleMaBnahmen prinzipiell vermeiden (vgl. An- 
hang C), jedoch geht dies i.a. zumindest bei verteilten Sy- 
stemen zu Lasten der erzielbaren Parallelitat und Perfor- 
manz, da zumindest dort das Wettrenn-Problem inharent ist 
und ohnehin gelost werden muss. 

Eine vom Wettrenn-Problem unabhangige Frage betrifft 
die „rechtma6ige" Ausubung „brutaler Gewalt", insbeson- 
dere der force-Modus. Es versteht sich von selbst, dass 
ein Eigentumer oder Hauptbesitzer groBe Macht Qber je- 
den ausuben kann, der etwas von ihm als Unterbesitz erhal- 
ten hat, da er auch dann auf Ruckforderung bestehen kann, 
wenn dadurch die Existenz des Unterbesitzers gefahrdet 
wird. Da die Besitzschuldverhaltnisse prinzipiell unabhan- 
gig von den in Abschnit t 2.7 besprochenen ZugrifTsrechten 

6 Wenn der Empfanger z.B. in eine Endlosschleife geht oder z B bei 
der Ausfiihrung der noti fy__*- Operation in einen Deadlock gerat oder 
wenn z.B. im RPC-Modell der Bearbeiter-Kontrollfluss verstirbt kann ei- 
ne ..Weigerung" auch schlicht darin bestehen, dass nichts geschieht Da 
interne Angelegenheiten eines Bausteins nicht von auBen „aufgemischt" 
werden sollten. bleibt zur Ldsung dieses Problems letztlich nur das Setzen 
einer Zeitschranke, deren Ablauf als „Weigerung M interpretiert wird 
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sind, konnte man die Frage stellen, ob diese Machtstelluno 
msbesondere von hierarchisch untergeordneten Instanzen 
nicht unangemessen sein konnte. Hierauf gibt es eine prin- 
zipielle Antwort: Nein. Wer (auf welche Weise auch immer) 
emmal die Macht erhalten hat, bestimmte Ressourcen ver- 
walten zu durfen, der kann von dieser Macht bereits bei der 
RessourcenvergabeunangemessenenGebrauch machen Er 
kann rein theoretisch bereits zu diesem Zeitpunkt ..bdsarti*" 
handeln und eventuelle Zugriffsbeschrankungen umgehen- 
em typisches Beispiel ist die Hauptspeicherverwaltung, die 
bei Kompromittierung samtliche Schutzmechanismen des 
gesamten Systems aushebeln kann, die auf ihr basieren 7 
Daher muss man einem Ressourcenbesitzer im Hinblick auf 
die Emhaltung geforderter Zugriffsrechts-Beschrankungen 
ohnehin vertrauen. Das Recht zur Ruckforderung ben6ti*t 
in dieser Sichtweise kein zusatzliches Vertrauen. Wenn ma°n 
emer Instanz nicht vertrauen kann, dann darf man sie von 
yornherein nicht mit der Verwaltung von Eigentum oder 
Unterbesitz beauftragen (z.B. indem man fur eine geeignete 
Aufteilung der Macht sorgt). 

Es gibt weitere Grunde, die den Entzug beliebiger Res- 
sourcen zu einem Pflicht-Mechanismus in zukunftssiche- 
ren Betriebssystemen machen. GroBrechner unterstiitzen 
seit langem das sogenannte „Hot-Plugging" von Hardware- 
Komponenten, also den Austausch mitten im laufenden 
Betrieb. Dies betrifft nicht nur CPUs, die in fast alien 
Betriebssystemen entziehbare Ressourcen darstellen, son- 
dern auch Speicher-Module. Die Problematik des Laufzeit- 
Austausches taucht fernerhin im IO-Bereich wie- z B bei 
RAID auf; bei sicherheitskritischen Anwendungen wird ein 
prophylaktischer Austausch von Hauptspeicher-Modulen 
manchmal sogar turnusmaBig durchgefuhrt. Die Fahigkeit 
zum Austausch im laufenden Betrieb erfordert einen Me- 
chanismus, mit dem der Entzug von Ressourcen in geord- 
neten Bahnen durchgefuhrt werden kann. 

Microsoft hat das Konzept der opportunistischen Locks 
[OpL] in die Betriebssystem-Schnittstelle der neueren 
Windows-Versionen integriert und damit zumindest fur ei- 
mge Anwendungen auch Anwendungsprograrnmen ver- 
fugbar gemacht. Opportunistische Locks 8 sind dazu ge- 
dacht, urn das Cache-Koharenz-Problem in verteilten Sy- 
stem durch den gezielten Entzug von Ressourcen zu be- 
schleunigen; wenn kein aktueller Bedarf fur einen Entzuo 
vorhanden ist, dann wird auf das zeitaufwendige Durcht 
rejchen der Ressource uber das Netzwerk verzichtet ( ag- 
gressives Caching"). Im hier vorgestellten Modell wirdder 
Entzug mittels brutaler Gewalt nur als letztes Mittel be- 
trachtet; fur das im nachsten Abschnitt naher behandel- 
te Cache-Koharenz-Problem wird der try-Modus favori- 
siert. Ein weiterer grundlegender Unterschied der hier fa- 
vonsierten spekulativen Locks zu opportunistischen Locks 

d J^r? n - C ! lt . 'J"? f derc InStanZ6n Wie 2 - B ' Wachter da ^" gehin- 
tlnZll \ • 1 Jed u° C , h kem Ge g enar e u ^nt, da eine Wachter-Instanz 
konsistenterweise auch die Rflckforderungen Oberwachen sollte. so dafl 

^z^z^s^ der Macht auf meh ™ in ~ 

"Microsofts opportunistische Locks sind stellen eine eigene Locking- 
nur £ S V °? an « er ! n 4 )C L king - A,ten "nabhangig sind. Dies erhoht nicht 
nur die Komplexttdt der Schnittetellen, sondern kann z.B. zu der Situati- 

ZS ZL maIi2i u Se Anwendun S- die einen opportunistischen 

Lock entzogen bekommen hat, mittels reguISrer Locks das System den- 
noch lahm legen kann. 
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besteht darin, dass auf Ruckforderungenim try-Modus 
nicht mit der Ruckgabe des gesamten gesperrten Berei- 
ches, sondern auch nur eines Teiles reagiert werden kann; 
dies ist insbesondere in Kombination mit der spekulati- 
ven Anforderung von vergroBerten Adress-Bereichen durch 
die try__address- und try__l en-Parameter vorteilhaft 
(vgl. Abschnitt 3.3.5). Die Unterscheidung zwischen einem 
Kernbereich und einem spekulativ erweiterten Bereich wird 
auch innotify_lockgetroffen;damitkann derEmpfan- 
ger einer Ruckforderung selbst entscheiden, wieviel er ohne 
groBere Behinderung seiner Arbeit zuruckgeben kann. 



5.3 



Synchronisation zwischen Kopi- 
en: spekulative Locks 



Verteilte Systeme unterscheiden sich aus Sicht der hier 
vorgestellten Architektur hauptsachlich 9 durch eine Ei- 
genschaft von einem alleinstehenden Rechner: das ist die 
Zugriffs- bzw Latenzzeit der remote- und mirror- 
]^g^|ie, sowie die maximale Datenrate, die ihren Durch- 
wSiJ enZt Dieses Prob,em tri " in Gestalt der bekann- 
t^j^^cherliicke" auch in alleinstehenden Systemen auf 
undist als so genanntes Flaschenhals- Problem lange be- 
kannt, das sich z.B. bei virtuellem Speicher als Thrashing 
(vgi. [DS72]) auBern kann. Die spezifische Problematik 
steckt bei verteilten Systemen lediglich im On (Hierarchie- 
Ebene), an dem sich der Flaschenhals befindet. 

Zur Losung des Flaschenhals-Problems gibt es zwei 
erprobte grundlegende Strategien: man versucht den 
Flaschenhals durch Hard ware- Aufriistung zu erweitern, 
und/oder die zur Losung einer Aufgabe notwendige Bela- 
stung zu senken. Wahrend sich bei der Hardware klassi- 
scher Peripheriegeraten in der Vergangenheit stand ige Fort- 
schritte sowohl bei den Latenzzeiten als auch beim Durch- 
satz ereignet haben und voraussichtlich weiter ereignen 
werden, sind derartige Fortschritte bei raumlich weit ver- 
teilten Systemen nur beim Durchsatz, nicht hingegen bei 
d !Lr^ " Z2eit m5 S lich [TL93]), da die Kommunika- 
t^^j^er Lichtgeschwindigkeit begrenzt wird. Daher ist 
ulKJSB Datenverkehr bzw. unnotiges Warten auf die Aus- 
ful^^von Operationen bei verteilten System noch drin- 
gender zu vermeiden als in alleinstehenden Systemen. Die 
hier vorgestelite Architektur legt auch aus diesem Grund 
besonderen Wert auf asynchrone Kommunikation, 

Wie bereits in Abschnitt 4. 1 .2 (Baustein buffer) darge- 
stellt, besteht der Zweck eines Caches in der Entkoppelung 
von Flaschenhalsen und der Reduktion der daruber laufen- 
den trans fer-Operationen. Wahrend bei alleinstehenden 
Rechnern Konfigurationen mit nur einer zentralen buf- 
f er-Instanz moglich sind, ist der Einsatz kaskadierter ver- 
teilter Caches (buf f er-Instanzen) bei verteilten Systemen 
aus Performanz-Grunden de facto unumganglich. Kaska- 
dierte Caches fuhren zwangslaufig zum bekannten Cache- 
Koharenz-Problem. 



Das Cache-Koharenz-Problem laBt sich in der Syste- 
matik der hier verwendeten Begriffe auf folgende Weise 
formulieren: es sind mehrere Besitzer derselben logischen 
Ressource vorhanden. 

Im Rechtswesen taucht dieses Phanomen in 
den Begriffen Geineinschaftseigentum (z.B. bei 
Wohnungseigentumer-Gesellschaften) und gemein- 
schaftlicher Besitz (z.B. Anmietung durch einen Verein) 
auf. Grundsatzlich sind mehrere Besitzer gleichberechtigt, 
und sie miissen sich bei alien Fragen betreffs des Besitzes' 
gegenseitig auseinandersetzen; dies geschieht im soge- 
nannten Innenverhaltnis. Der Grund hierfur ist, dass ein 
Besitz exklusiv nutzbare Eigenschaften haben kann, so 
dass eine gleichmafiige und/oder gleichzeitige Nutzung 
durch alle Besitzer nicht immer moglich ist. 

Die Auseinandersetzung uber exklusiv nutzbare Ressour- 
cen findet in traditionellen alleinstehenden Betriebssyste- 
men bevorzugt durch Delegation der Verwaltungsaufgaben 
an eine zentrale Instanz (z.B. ein Lock-Manager) statt. Die- 
se Losung hat den Vorteil hoher Einfachheit bei geringen 
Kosten, da durch die Delegation praktisch vernachlassigba- 
re Latenzen entstehen. In einem verteilten System ist dage- 
gen eine Delegation an eine einzige Instanz i.a. wegen der 
Kommunikations-Latenzen sehr kostenintensiv. 

Man kann sich Worst-Case-Zugriffsszenarien ausden- 
ken, bei denen die Latenz-Kosten eines verteilten Systems 
zwangslaufig bei jedem einzelnen Zugriff entstehen miis- 
sen, weil sie wegen einer „genugend bosartigen" Aufga- 
benstellung nicht zu umgehen sind (analog zum Working- 
Set-Modell). Dies trifft ubrigens auch fur Caches alleinste- 
hender Systeme zu, die man ebenfalls mit solchen Zugriffs- 
mustern belasten kann, dass sie den bekannten Thrashings 
Effekt zeigen, bei dem sie ihre Wirksamkeit fast vollstan- 
dig einbiiBen konnen. Bei alleinstehenden Systemen gilt 
die lange bekannte Grundregel, dass Thrashing nur dann 
vermeidbar ist, wenn der Working Set [Den68J der Last in 
den Cache passt Diese lange bekannte Grundregel gilt aber 
auch in einem verteilten System mit mehreren Caches, al- 
lerdings in nochmals verscharfter Form. Schauen wir'uns 
dazu das folgende Szenario aus mehreren ortlich weit ver- 
teilten Caches an, die ich „hierarchisch hochstehende Ca- 
ches" nenne, die an einen gemeinsamen Basis-Cache ange- 
schlossen sind: & 



Das haufig angefdhrte Problem der Ausfaltstcherheit sehe ich nicht als 
spezifisch for verteilte Systeme an, obwohl eine brauchbare Ldsung dort 
von besonderer Wichtigkeit ist. Konzepte zur Erzielung von Ausfallsicher- 
heit sollten fUr alle Bausteine uniform sein, unabhangig von der konkreten 
physischen Verteilung. 



Damit uberhaupt ein Entkopplungs-Effekt durch die hoch- 
stehenden buf f er-Instanzen entstehen kann, miissen ih- 
re Working-Sets, bezogen auf die zeitliche Gro!3enordnung 
der Kommunikations-Latenzen, „einigermassen disjunkt" 
sein. Andernfalls tritt analog zu [DS72] zwangslaufig ein 
Thrashing-Effekt zwischen den hochstehenden buf f er- 
Instanzen ein, der in der hier gewahlten Hierarchie-Struktur 
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uber die untenstehende Basis-buT f er-Instanz abgewickelt 
wird und auch durch VergroBerung der Caches nicht elimi- 
nierbar ist, wie Denning sehr einleuchtend bereits vor lan- 
ger Zeit gezeigt hat Gegen diese Art von Thrashing hilft 
meiner Ansicht nach uberhaupt kein Kraut: es ist verteil- 
ten Systemen.inharent, dass modifizierte Daten irgendwie 
an den Ort der anderen buf f er-Instanz gebracht werden 
mussen, wenn sie dort von der Aufgabenstellung her unbe- 
dingt benotigt werden, und das kostet zwangslaufig Latenz- 
zeit (weil die Lichtgewindigkeit als Naturkonstante nicht 
umgehbar ist). Ich sehe daher keine andere Moglichkeit, 
als die Aufgabenstellung so zu gestalten, dass ein derarti- 
ges Thrashing nicht stattfindet Dazu ist eine notwendige 
Bedingung, dass die Working-Sets an verschiedenen Orten 
einigermassen disjunkt voneinander sein mussen. 

Unter der Annahme, dass die Working-Sets der hoch- 
stehenden buf f er-Instanzen disjunkt sind, sieht die L6- 
sung des Problems folgendermassen aus: es ist nichts ande- 
res zu tun, als die vorkommenden Working-Sets einigerma- 
Ben genau zu bestimmen. Dies machtein ausschlieBlich von 
Anforderungen getriebener Cache von Natur aus ganz von 
selbst. Anders sieht die Situation hochstens dann aus, wenn 
das Laden der oberen Cache-Instanzen mit Daten zusatz- 
Iich auf spekulative Weise erfolgt, z.B. beim sogenannten 
Preloading. 

Zur Analyse des Preloadings sehen wir uns den Best Ca- 
se an, bei dem wir die folgenden idealisierten Annahmen 
treffen: 

1 . Die Caches seien jeweils geniigend groB, so dass alle 
insgesamt benotigten Datenmengen in jedem einzef- 
nen Cache Platz haben. 

l 

2. Die Datenubertragungs-Rate sei naherungsweise un- 
endlich groB, die Latenzzeit dagegen ein fester Wert 
echt grofier Null. 

3. Jegliche Anderung eines Datums werde sofort an alie 
anderen Cache-Instanzen propagiert (was wegen der 
unendlichen Dateniibertragungs-Raten auch kein Pro- 
blem darstellt); diese Propagation kostet naherungs- 
weise nichts. 

4. Welche Version eines Datums wahrend der 
Kommunikations-Latenzzeiten an welcher Stelle 
zur Verfugung steht, wird idealisierend als standig 
libera! I bekannt vorausgesetzt. 

Trotz dieser bestmdglichen Annahmen, die unter der vor- 
gegebenen raumlichen. Verteilung nicht mehr zu verbes- 
sern sind, kann hier immer noch ein Trashing zwischen den 
hochstehenden Caches stattfinden, sofern man nur die An- 
forderungen durch die Aufgabenstellung geniigend „bosar- 
tig" gestaltet. Ist diese Bosartigkeit jedoch nicht gegeben 
(weil die Working Sets aller Teilnehmer-Instanzen disjunkt 
sind), dann braucht niemals irgend eine buf f er-Instanz 
auf eine andere zu warten. Damit haben wir den Best Ca- 
se dessen, was mit Hilfe von Caching-Strategien uberhaupt 
erreichbar ist, namlich die totale Entkopplung aller Aktivi- 
taten und damit die Illusion, dass Latenzzeiten nicht vor- 
handen seien. 



Da die getroffenen Annahmen in der Praxis naturlich 
nicht zutreffen 10 , lautet die Frage, wie man den Best Ca- 
se approximieren kann. Fur die Annahme 1 gibt es lan^e 
bekannte und erprobte Strategien der Adaption von Caches 
an die Working-Sets der Anforderungen, insbesondere LRU 
und LFU. Zur Losung des Problems 2 wird insbesonde- 
re in Hardware-Architekturen (beispielsweise in Prozessor- 
Cache-Hierarchien) die explizite Priorisierung der Daten- 
transfers eingesetzt: beim Transport durch einen Flaschen- 
hals mussen solche Transport-Auftrage dringender behan- 
delt werden, von deren Ausfuhrung andere Aktivitaten 
abhangen; dagegen sollten spekulative Transport-Auftrage 
unbedingt geringer priorisiert werden, urn dringendere Ak- 
tivitaten nicht durch Verstopfung des Flaschenhalses zu be- 
hindern. Dies wird bei der hier vorgestellten Architektur 
durch die IO-Prioritaten ermoglicht (siehe Abschnitt 2.8.3). 
Das Problem 3 lasst sich dadurch losen, dass jegliche An- 
derungen grundsatzlich sofort 11 durch Erzeugen eines IO- 
Auftrages (transfer-Operation) bekannt gemacht wer- 
den, allerdings standardmaBig nur mit Background-IO- 
Prioritat, die nur bei Vorliegen hoherer Dringlichkeit erhoht 
wird. Das Problem 4 erfordert eine genauere Analyse: 

Wie bereits in Abschnitt 3.3.3 dargestellt und in Ab- 
schnitt 5.1 begriindet, erfordert die Verwaltung von Besitz 
eine transiente Zuordnung des Besitz-Status (z.B. als Refe- 
renzzahler, ggf. auch der Versions-Zuordnung). Dieser Sta- 
tus ist an den Ort gekoppelt, fur den der jeweilige (Unter- 
)Besitz-Status verwaltet wird. Da alle hochstehenden Ca- 
ches aus Sieht des Basis-Cache Konsumenten sind, mus- 
sen sich diese wie alle anderen parallel arbeitenden Konsu- 
menten an ein multi*-Verhalten halten, urn die Determi- 
nanz fur ihre jeweiligen Konsumenten sicherstellen zu kon- 
nen. Daraus folgt inbesondere, dass Locks prinzipiell bis 
auf den Basis-Cache durchgereicht werden mussen, anson- 
sten konnten die Verhaltens-Modelle verletzt werden. Wenn 
man jeden Lock einzeln durchreichen wurde, dann ent- 
stunde jedesmal eine Wartezeit durch die Kommunikations- 
Latenzen, was sich katastrophal auf den Durchsatz auswir- 
ken wurde. Diese Pfiicht zum Durchreichen ist jedoch ei- 
ne Mindest-Anforderung, die auch ubererfullt werden darf. 
Die Idee besteht nun darin, dass bei der erstmaligen An- 
forderung eines Locks nicht die vom Endkonsumenten an- 
geforderte Granularity durchgereicht wird, sondern mog- 
lichst ein spekulativ vergrofierter Adressbereich (z.B. ein 
gesamtes Unter-Nest oder ein gesamtes Verzeichnis-Nest). 
Ein dazu geeigneter Mechanismus ist bereits in Abschnitt 
3.3.5 vorgestellt worden (Parameter try_address und 
try_len). Wenn es einem der hochstehenden Caches ge- 
lungen ist, den Working Set seiner Konsumenten einiger- 
massen realistisch spekulativ einzuschatzen, dann braucht 
er spatere Lock- Anforderungen seiner Konsumenten nicht 
jedesmal Zeit raubend zum Basis-Cache durch zu schalten, 
sondern kann den bereits erhaltenen spekulativen Besitz oh- 
ne Wartezeit an seine Konsumenten als Unterbesitz weiter 
geben, sobald diese eine entsprechende Anforderung stel- 

,0 Die Fortschritte bei den Kommunikationstechniken gehen jedoch in 
die Richtung, dass die Best-Case-Annahmen immer besser durch verbes- 
serte Technik angenahert werden. 

"Damit ist nicht die Granularitat einzelner Schreibe. 
Maschinenoperationen gemeint, sondern eine ,^eitnahe M Meldung in 
der GroBenordnung der Kommunikations-Latenzen. 
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' len. Zu beachten ist dabei lediglich, dass spekulativ vorab 
angeforderte Lock-Arten die korrekte Semantik bei spaterer 
Nachforderung durch die Endkonsumenten ergeben miis- 
sen; i.a. wird man dabei statt eines Read-Locks einen Write- 
Lock spekulativ anfordern miissen, urn die Aktualitat der 
neuesten Version garantjeren zu konnen (ansonsten konnten 
andere Instanzen Veranderungen vornehmen, die zu einem 
unbemerkten Veralten der spekulativ angeforderten Version 
fiihren). 

Spekulationen tiber den zukUnftigen Working-Set der 
Endkonsumenten konnen insofern fehl gehen, als dass zu 
grosse Bereiche vom Basis-Cache angefordert wurden, die 
spater doch noch von anderen hochstehenden Caches beno- 
tigt werden 12 . Fehlspekulationen lassen sich durch Ruckfor- 
derungen mittels notify_*-Operationen korrigieren. Der 
Basis-Cache kann grundsatzlich bei Anforderung bereits 
vergebener Locks entsprechende notify_*-Operationen 
an den/die momentane(n) Besitzer-Instanz(en) generieren. 
Falls er sich die Unterschiede zwischen vergebenen Kern- 
und Erweiterungsbereichen merkt (sowie ggf. von spater 
hin^commenden Kernbereichen durch den neuen Besit- 
^ah, aber asynchron informiert wird), kann er auf 
c^^^Bsn „aussichtsloser" Riickforderungen, die verge- 
beWIKrnbereiche betreffen, auch verzichten. Ruckforde- 
rungen von Kernbereichen sollten moglichst nur fur solche 
Adressbereiche gestellt werden, die ein anderer Cache auch 
wirklich aktuell benotigt. Es ist Sache des Fehlspekulanten, 
ggf. auch grofiere Bereich als den aktuell zuruck geforder- 
ten oder sogar groBere als den vorgeschlagenen Erweite- 
rungsbereich an den Basis-Cache zuruck zu geben, urn da- 
mit weiteren zukunftigen Riickforderungen spekulativ vor- 
zubeugen. Eine Ruckgabe ist daruber hinaus auch jederzeit 
spontan moglich, beispielsweise wenn erkann^ wurde, dass 
ein bestimmter Bereich auf jeden Fall nicht mehr benotigt 
wird. 

Insgesamt bewirkt diese Vorgehensweise eine spekulati- 
ve Vorab- Verteilung von Ressourcen, die durch die aktuel- 
len Anforderungen nachtraglich korrigiert wird. Die Ruck- 
gabe spekulativ angeforderter Ressourcen kann durch ver- 
Strategien erfolgen. Eine mcjgliche Ruckgabe- 
Jist, den zwischen dem nachstliegenden tatsach- 
Itgenutzten Bereich und dem ruckgeforderten Be- 
liegenden spekulativ angeforderten Bereich zu halbie- 
ren, also die Halfte weiter zu behalten, die andere Halte 
dem Ruckforderer zu iiberlassen. Falls die Working Set? der 
Endkonsumenten disjunkt und naherungsweise zusammen- 
hangend sind, dann ergibt sich dadurch im Worst Case ei- 
ne logarithmische Anzahl von Riickforderungen (in Abhan- 
gigkeit von der GroBe des aufzuteilenden Adressbereiches). 
Nach dieser hochstens logarithmischen Anzahl an Ruckfor- 
derungen ist der vorab unbekannte genaue Verlauf der dis- 
junkten Working Sets empirisch festgestellt worden, und es 
finden keine weiteren Riickforderungen mehr statt (einge- 
schwungener Zustand des Systems). Nach dem Einschwin- 
gen sind keine weiteren Synchronisationen mehr erforder- 
lich, sofern sich die Working Sets nicht andern; damit ist 
der obige Best Case relativ gut approximiert. Bei Jangsa- 




men" Anderungen der Working Sets finden zwar ab und zu 
noch Riickforderungen statt, diese haben jedoch ein rela- 
tiv geringes Gewicht in den Gesamtzahl aller Operationen; 
damit ist hier ebenfalls der Best Case relativ gut approxi- 
miert. Bei zu starker Uberlappung der Working-Sets bzw 
zu groBer Anderungsrate kann es zu einem Thrashing kom- 
men, das jedoch laut obiger Argumentation prinzipiell nicht 
vermeidbar ist. 



,2 FaIls die Annahme disjunkter Working Sets doch nicht zutreffen soll- 
te, liegt bei der hier vorgestellten Betrachtungsweise die „Schuid" nicht 
bei den Caches, sondern beim Verhalten der Endkonsumenten. 



Kapitel 6 

Generische Operationen 



Generische Operationen sind Operationen, die uber eine 
polymorphe Schnittstelle aufrufbar sind. 

In Betriebssystemen wird das Paradigma der Generizi- 
tat bzw. der Polymorphie bereits sehr lange eingesetzt; be- 
kannte Beispiele finden sich u.a. bei polymorphen Kern- 
Schnittstellen wie ioctl in Unix, oder bei den Operations- 
Sprungtabellen von IBM-Betriebssystemen, die verschiede- 
ne Arten von Polymorphie bereits in den 1960er Jahren im- 
plementierten. 

Bevor wir zur Untersuchung der Arten von Polymorphie 
kommen, mochte ich klaren, was ein Operations-Aufruf 
ttberhaupt ist: 

Ein Operations-Aufruf ist die Ubergabe von Information 
von einer Aufrufer-Instanz an eine Bearbeiter-Instanz. 

Nach dieser Definition ist die Ruckgabe von Ergebnis- 
sen, z.B. in Ergebnis-Parametern, ebenfalls ein Operations- 
Aufruf, .nur in umgekehrter Richtung, d.h. vom urspriing- 
lichen Bearbeiter zuriick zum urspriinglichen Aufrufer. In 
diesem Fall spricht man von einem Operations- Aufrufs- 
Paar. 

Operations- Aufrufe bzw -Paare lassen sich auf verschie- 
dene Weisen realisieren. Bekannte Real is ierungs- Arten sind 
z.B. Prozeduraufrufe mittels Ubergabe von Parametern auf 
dem Stack eines Programmiersprachen-Laufzeitsystems, 
oder der RPC (Remote Procedure Call). Ersterer Fall laBt 
nur den synchronen Aufruf letzterer Fall auch den asyn- 
chronen Aufruf zu. Weitere bekannte Realisierungs-Arten 
sind das Starten von Kontrollflussen (asynchrones Ver- 
halten), oder die Weitergabe der Flusskontrolle in einem 
Coroutinen-Modell durch Aufruf einer Transfer-Operation 
(dies bewirkt synchrones Verhalten aus Sicht des Gesamt- 
sy stems). 

Ich mochte auf eine weitere bekannte Art der Realisie- 
rung von Operations- Aufruf en fokussieren: das so genann- 
te Nachrichten-Paradigma\ das zwar oft im Kontext von 
CSP (siehe [Hoa78]) in Erscheinung tritt, prinzipiell je- 
doch unabhangig von sequentiellen Kontrollflussen ist. Das 
Nachrichten-Paradigma wird grundlegend in der Hardware 
verwendet und steckt z.B. hinter den weit verbreiteten read- 
write-Schnittstellen, bei denen ja auch Informationen von 

'Nachrichten dienen zur Obertragung von Information (umgekehrt 
kann jedoch auch das Nicht-Senden oder das Nicht-Ankommen einer 
Nachricht eine Information darstellen, z.B. beim Ablaufen eines Timeouts; 
vgl. [Lam84]). Eine Obertragung von Information muss nicht unbedingt 
durch Herstellen einer Kopie erfolgen; beispielswelse stellt auch die Be- 
nutzung eines gemeinsamen Puffers durch mehrere Instanzen eine Reali- 
sierung einer Nachrichten-Ubertragung dar. 



einer Instanz an eine andere weitergegeben werden. 

Man sollte sich unbedingt klar machen, dass zwischen ei- 
ner reinen Nachrichten-Ubertragung und einem Operations- 
Aufruf Uberhaupt kein prinzipieller Unterscliied besteht. 
Ein solcher Unterschied entsteht erst durch die Interpreta- 
tion der Nachricht durch den Empfanger, sowie ggf. durch 
seine Reaktion auf die interpretierte Nachricht 

Dies bedeutet fur unsere Betriebssystem-Architektur, 
dass wir zur Realisierung von generischen Operationen kei- 
ne neuen Konzepte einfuhren mussen, sondern die bereits 
ausfiihrlich vorgestellten Abstraktionen Nest und Baustein 
verwenden konnen. 

Konkret wird dies z.B. auf folgende Weise realisiert: 
Einer Nest-Instanz s wird ein so genanntes Operations- 
Nest als dynamisches Attribut zugeordnet, oder mit Hilfe 
einer einer eigenen Elementarfunktion get_ops(s). Das 
Operations-Nest dient zum Austausch der Nachrichten fur 
die generischen Operationen, die auf dem zugeordneten 
Nest $ ausgefuhrt werden sollen. Zu einem Operations-Nest 
op kann man umgekehrt das zugeordnete Nest durch eine 
Elementarfunktion get_nest(op) zuganglich machen. Es 
gilt dann get_nest(get_ops(s)) = s. 

Zum Austausch der Nachrichten werden die in Abschnitt 
3.3.8 behandelten Elementaroperationen get_address, 
put_address, get, put , transfer und wait 
verwendet. Das Operations-Nest darf zu einem be- 
Iiebigen Zeitpunkt mehrere Operations-Aufrufe enthal- 
ten und ist daher prinzipiell geeignet, urn die Funk- 
tionalitat von Auftrags-Warteschlangen, Geratetreiber- 
Warteschlangen u.a. auszufuhren. 

Zum Ubertragen der Nachrichten in einem Operations- 
Nest mussen auf jeden Fall Elementaroperationen verwen- 
det werden 2 , die an einen Schnittstellen-Mechanismus aus 
Abschnitt 2.3.2 gebunden sind, und mit deren Hilfe erst 
das Konzept der generischen Operationen auf einer hoheren 
Abstraktionsstufe implementiert wird. Rein theoretisch wa- 
re es moglich, auf die Implementierung der Elementarope- 
rationen im zugeordneten Nest zu verzichten und diese aus- 
schliefilich durch generische Operationen im zugehorigen 
Operations-Nest auszufuhren. Nicht nur aus Performanz- 
Griinden, sondern auch aus Symmetriegrunden propagiere 
ich die umgekehrte Methodik, dass Elementaroperationen 
auf beide Arten aufrufbar sein sollen (und dabei dasselbe 
tun sollen). Es spielt dann keine Rolle, ob Elementaropera- 

2 Dies HeBe sich durch Benutzung von get_ops(get_ops(s)), also 
EinfUhren eines Operations-Nestes zum Operations-Nest vermeidcn. 
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tionen direkt auf dem zugeordneten Ne^iufgerufen wer- 
den oder indirekt liber das Operations-Nest in Auftrag ge- 
geben werden 3 . Es ware jedoch zu uberlegen, die Opera- 
tionen lock und unlock ausschliesslich mittels generi- 
scher Operationen zu realiseren und damit nicht mehr a!s 
Elementaroperationen zu betrachten, da diese fur die Her- 
stellung von generischen Operationen nicht benotigt wer- 
den; damit wurden die Schnittstellen-Mechanismen aus Ab- 
schnitt 2.3.2 die Eigenschaft der Minimal itat erfullen. 

Weiterhin bietet ein Operations-Nest die Moglichkeit zur 
atomaren Bilndelung von Lock-Operationen. Dazu werden 
mehrereLock-Operations-Beschreibungenin ein gemeinsa- 
mes Datenpaket gepackt. Die Ausfiihrung erfolgt entweder 
zusammen als atomare Einheit oder gar nicht. Damit lasst 
sich insbesondere das Handwerker-Problem [Jur73] ohne 
Einfuhrung weiterer Konzepte losen. Bei der Biindelung 
mehrerer wait-Operationen lieBe sich die Sernantik dis- 
junktiven Wartens ohne Einfuhrung zusatzlicher Konzepte 
realisieren. 

Nun zur Problematik der Polymorphic Aufrufer und Be- 

•arbeiter mussen eine generische Operations-Nachricht auf 
der passende Weise interpretieren, sonst entsteht ei- 
|unktion des Systems, 
nformationen daruber aufzubewahren, wie ein Nest- 
Inhalt zu interpretieren ist, ist das Konzept des Meta-Nestes 
vorgesehen (vgl. Operation getjneta in Abschnitt 3.4.5; 
vgl. Abschnitt 4.2) 4 . Dies kann nun analog auf Operations- 
Nester ubertragen werden. Das Operations-Meta-Nest soli 
einen Kotisens zwischen dem Aufrufer und dem Bearbeiter 
uber die zu verwendenden Datenformate bzw Datentypen 
vermitteln. 

Wir brauchen also ein Typsystem, wie es prinzipiel! 
bei Programmiersprachen schon lange einges'etzt wird. In 
der Literatur dieses Gebiets wenden unzahlige Varianten 
von Typsystemen behandelt. Die Auswahl eines konkreten 
Typsystems fallt Ieichter, wenn man sich folgende Anforde- 
rungen vor Augen halt, die auch schon bisher in Betriebs- 
systemen traditionell eine groBe Rolle gespielt haben: 

l^ine Typprufung (d.h. ein Test, ob zwei Datenforma- 
ueinander passen) braucht nur zur Laufzeit erfol- 
I Es gibt genugend Anwendungsfalle, wo dies auf 
Ben Fall erst zur Laufzeit geschehen kann; dynami- 
sche Typprufungen sind also unbedingt erforderlich 
und konnen statische Typpriifungen notfalls vollstan- 
dig ersetzen 5 . Als Konsequenz hieraus brauchen sta- 
tische Typprufungen hdchstens bei einfachen Grund- 
Datentypen und nicht notwendigerweise bei komple- 
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♦ In letzterem Fall ist ein asynchmncr Aufruf mSglich. Wie viel Sinn 
dies macht. sei dahingestellt, da die Elementaroperationen eigens zur Dar- 
stellung von Asynchronitat entwickelt wurden. 

4 Das beim RPC oft als notwendig betrachtete Marshaling (Umwand- 
lung zwischen inkompatiblen Datenformaten) wird hier nicht in die Grand- 
mechanismen hineingesteckt, sondern kann bei Bedarf durch Anpassungs- 
bausteine implementiert werden. die verschiedene Datenformate ineinan- 
der umwandeln. 

5 Bei genauer Betrachtung aktueller monolithischer Kern- 
Implementierungen im Unix-Umfeld fallt auf, dass diese exzessiven 
Gebrauch von dynamischen TVppriifungen machen. Dies wird z.B. durch 
die Existenz der Fehler-Riickmeldung BINVAL (Invalid Argument) in 
Unix belegt. Bs gibt kaum Systemaufrufe, die Parameter verlangen, wo 
statt der Bearbeitung eines Aufruf- Auflrages nicht dieser Fehlercode als 
RUckmeldung zurackkommen kann. 



xen Datentypen vorgesehen zu werden. Dies verein- 
facht ein Typsystem enorm. 

2. Welche Typen (d.h. Datenformate) ein Bearbeiter ak- 
zeptieren und bearbeiten kann, kann nur dieser allei- 
ne festlegen. Typ-Informationen dienen zur Einweg- 
Kommunikation zwischen Bearbeiter und Aufrufer; 
damit kommen komplexere Mechanismen wie Typ-' 
Inferenzsysteme nicht aufSysteniebene 6 in Frage. 

Es ist klar, dass trotz dieser Einschrankungen viele ver- 
schiedene TVpsysteme und noch mehr konkrete Realisie- 
rungen derselben in Frage kommen. In nachsten Abschnitt 
werde ich zwei einfache Typsystem vorstellen, die wichti- 
ge Grundfunktionen abdecken sollten und Iediglich als Bei- 
spiele zu verstehen sind. 

6.1 Beispiel-iypsysteme 

Einige Betriebssystem-Konstrukteure haben sich in der Ver- 
gangenheit geweigert, Typkonzepte einzufuhren, was u.a. 
zu derhistorischen Spaltung zwischen Betriebssystem- und 
Datenbank-Konstrukteurebeigetragen hat. Argumente hier- 
fur waren oder sind immer noch, dass im Betriebssystem 
fest verankerte Typen die Flexibility mindern, die Schnitt- 
stellen verkomplizieren und obendrein Performanz kosten. 
Ich hoffe, diese Sichtweise relativieren zu konnen. Es geht 
mir nicht darum, fest verankerte Typen einzufuhren, son- 
dern auf der Basis generischer Schnittstellen die Deklarati- 
on beliebiger Typen zu ermoglichen, indem es erweiterbar 
ist. Typbeschreibungen stellen ein optionales Konzept dar, 
das auch weggelassen werden kann; dann erhalt man Gene- 
nzitat in Reinkultur. Richtig eingesetzt, kann es generische 
Schnittstellen erganzen und vereinfachen, indem traditio- 
nell von Hand codierte Vorgange (beispielsweise bei Ver- 
wendung von Assembler bis in 1970er Jahre hinein) auto- 
matisiert werden. Ich versuche in den folgenden Beispielen 
zu zeigen, dass exzellente Performanz von Typprufungen 
durch die Wahl geeigneter Sprachklassen und Kodierungen 
erreichbar ist. 

6.1.1 Minimal-Typsystem 

Hier geht es urn die Frage, was ein Typsystem unbe- 
dingt enthalten muss, damit generische Operationen eini- 
germaBen brauchbar und benutzbar sind. Alles, was dazu 
nicht erforderlich ist, versuchen wir weg zu lassen und auf 
Laufzeit-Tests durch den Bearbeiter zu verlagern. 

Wenn ein Operations-Nest mehrere verschiedene generi- 
sche Operationen ermoglichen soil, dann gibt es eine Infor- 
mation, die in jedem Falle sowohl beim Aufrufer als auch 
beim Bearbeiter vorhanden sein muss: der Name der Ope- 
ration. 

Eine einfache Realisierung eines Mi nimal-Typsy stems 
besteht darin, dass das Meta-Nest des Operations-Nestes 

6 Damit sind TVp-Inferenzsysteme jedoch nicht generell ausgeschlos- 
sen: die Abschnitt 4.2.2 vorgestellten strategy_*-Bausteine konnen 
nicht nur Laufzeit-Test auf Typkompatibilitat auszufUhren, sondern im 
Pnnzip beliebige Folge-Instantiierungen mit beliebigen Parametem aus- 
ldsen. Damit sollte es theoretisch meglich sein, sogar ein Hindley-Milner- 
Typsystem zu realisieren. 
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eine Liste der implementierten zueinander disjunkten Ope- 
rationsnamen enthalt. Diese Liste laBt sich beispielsweise 
als luckenlos liegende Folge von Paketen realisieren, deren 
Grenzen im adjungierten Nest des Meta-Nestes angezeigt 
werden. Fur die Kodierung der Operationsnamen kommen 
beispielsweise Text-Zeichenketten in Frage, die gegeniiber 
Integer-Konstanten 7 zu bevorzugen sind. 

Mehr braucht ein minimales Typsystem nicht zu enthal- 
ten 8 ; ob die Anzahl, GroBen und Werte der Operations- 
Parameter korrekt sind, kann der Bearbeiter selbst prufen 
und ggf. mit der Rucklieferung einer Fehlermeldung rea- 
gieren. 

6.1.2 Einf aches erweiterbares Typsystem 

Das soeben vorgestellte minimale Typsystem ist bereits in- 
sofern erweiterbar, als dass der Wertevorrat fur die Kodie- 
rung der Operationsnamen so groB gewahlt werden kann, 
dass zukunftige Erweiterungen um neue Operationen prak- 
tisch unbeschrankt moglich sind. Es geht jetzt um die Fra- 
ge von Schnittstellen-Erweiterungen, die man unter die Ru- 
brik ^Erweiterungs-Generizitat" (vgl. Abschnitt 2.1.2) ein- 
ordnen kann 9 . Bei der hier vorgestellten Architektur ist vor 
dem Einsatz von Erweiterungs-Generizitat unbedingt ge- 
wissenhaft zu prufen, ob der gleiche Effekt nicht auch durch 
kompositorische Generizitat (vgl. Abschnitt 2.1.3) erreich- 
bar ist Kompositorische Generizitat hat grundsatzlich Vor- 
rang vor Erweiterungs-Generizitat; dieses Philosophic ist 
ein wichtiges Unterscheidungsmerkmal des hier vorgestell- 
ten Ansatzes gegenuber den meisten konkurrierenden An- 
satzen. 

In der Literatur aus dem Gebiet der Programmierspra- 
chen werden Typsysteme als algebraische Struktur aufge- 
fasst, fur die eine abstrakte Syntax angegeben werden kann 
und meist auch nur angegeben wird. Dies genugt i.A. fur 
unsere Zwecke nicht: ein Betriebssystem muss auch die 
konkreten Datenformate (sog. Aufruf-Konventionen) fest- 
legen, da die System-Schnittstellen iibergreifend fur unter- 
schiedliche Aufrufer-iypen gelten sollen, insbesondere den 
Anschluss an unterschiedliche Programmiersprachen und 
Laufzeitsystem-Modelleermoglichen sollen. Wir benotigen 
daher eine Spezifikation der algebraischen Struktur in kon- 
kreter Syntax 10 . 



7 Diese werden z.B. in Unix zur Unterscheidung der durchzufUhrenden 
Operationen bei ioctl und f cntl eingesetzt. Ober die damit verbun- 
denen Probleme und Auswirkungen ist bereits gentigend in der Folklore- 
Literatur diskutiert worden. Bei der Geschwindigkeit heutiger Prozessoren 
kann der minimal groBere Aufwand beim Zugriff auf Zeichenketten ge- 
genQber dem Zugriff auf ein Maschinenwort kein schlagendes Argument 
mehr sein, vor allem, wenn man den Zugewinn an Komfort dagegen steliL 

R Man kannte theoretisch sogar noch die Liste der Operationsnamen 
weglassen. Der Bearbeiter kann dann zwar das Datenformat aller einge- 
henden Auftrage selbst prufen, der Aufrufer ist in diesem Falle aber voll- 
kommen ..blind" und kann die Operations-Namen nur erraten, wenn er 
sie nicht aus einer anderen externen Quelle (wie z.B. eine Schnittstellen- 
Definition) weiB. Wenn (iberhaupt keine Typinformation kommuniziert 
wird, dann handelt es sich nicht um ein Typsystem im eigentlichen Sin- 
ne. 

9 Diese Problematik taucht in Beiriebssystemen immer wieder auf, und 
zwar nicht nur in solchen, die Objektorientierung als Leitmotiv angeben. 
Microsoft hat beispielsweise den Begriffder „DLL-H51Ie" gepriigt. Damit 
sind zueinander inkompatible Versionen von Systembibliotheken gemeint, 
die aufgrund intern geSnderter Schnittstellen nicht zusammenpassen. 

,0 Beispiele fdr die konkrete Syntax von system-Ubergreifenden Schnitt- 
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Zur Spezifikation einer konkreten Syntax eignen sich be- 
kanntermaBen kontextfreie Grammatiken. Diese bringen je- 
doch in ihrer Allgemeinform das Problem der Mehrdeutig- 
keit mit sich: bei unbedachter Verwendung zur Beschrei- 
bung von Datenformaten kann es vorkommen, dass ein kon- 
kret vorliegendes Datenformats-Muster verschiedene Inter- 
pretationen zulasst. Aus der Theorie der formalen Sprachen 
ist bekannt, dass die Mitgliedschaft einer beliebigen Grarn- 
matik in der Klasse der eindeutig kontextfreien Sprachen 
nicht entscheidbar ist; zum Gluck gibt es jedoch entscheid- 
bare Unterklassen wie die bekannten LR(k) oder LL(k)- 
Grammatikklassen. Diese sind nicht nur entscheidbar, son- 
dern reichen fur praktische Zwecke vollkommen aus 1 1 . 

Ich mochte noch einen Schritt weitergehen und zeigen, 
dass fur die Zwecke von Betriebssystemen die Klasse derje- 
nigen XL (1) -Grammatiken ausreichend ist, die sich zusatz- 
lich in Greibach-Normalform 12 befinden. Das Wortproblem 
bzw. das Parsing-Problem ist bei diesen Grammatiken tri- 
vial losbar, da man beispielsweise das bekannte Verfahren 
des rekursiven Abstiegs in interpretativer Weise direkt auf 
einer Kodierung der Grammatik ausfuhren kann, ohne die 
bei LL(l) notwendigen FIRST-Mengen berechnen zu mus- 
sen, da diese trivialerweise mit dem ersten Terminalsymbol 
ubereinstimmen, mit dem jede Grammatikregel wegen der 
Greibach-Normaiformbeginnen muss. Die beim rekursiven 
Abstieg notwendigen Parsing-Entscheidungen werden da- 
durch trivial. 

Um sicherzustellen, dass eine Greibach-Grammatik auf 
jeden Fall die £L(l)-EigenschafterfuIIt, gibt es eine einfa- 
che Methode, die leicht zu erlernen und zu beherrschen sein 
diirfte: Man verlangt als Ersatz-Forderung fur die LL(1)- 
Eigenschaft, dass keine verschiedenen Produktionsregeln 
der Form X aa und X -> a0 mit gleichem Nicht- 
terminalsymbol X und gleichem Terminalsymbol a, aber 
verschiedenen Fortsetzungen a und 0 vorkommen durfen. 
Diese Forderung laBt sich dadurch einhalten, dass man fur 
a bzw. P ein neues Nichtterminalsymbol Y einfuhrt, das die 
Rolle der bisherigen Reste a und P gemeinsam ausfuhren 
und iibernehmen soli. Da alle Produktionen fur Y wieder- 
um den gleichen Erfordernissen unterliegen, ergibt sich die 
LL(1)-Eigenschaft beim Entwurf der kontextfreien Gram- 
matik durch einen Menschen ganz von selbst. Ich nenne ei- 
ne Greibach-Grammatik mit dieser Ersatz-Forderung eine 
Typ-Grammatik. 

Eine Typ-Grammatik setzt die folgenden bekannten 
Grundprinzipien des Entwurfs von Datenstrukturen direkt 
in leicht zu handhabende Grammatik-Regeln um: 

• Die Schachtelung 

• Die Sequenz 

• Die Alternative 

stellen finden sich u.a. in den Internet-RFCs (Request For Comments). Da- 
tenformate werden dort fast durchwegs durch kontextfreie Grammatiken in 
einer zur Backus-Naur-Form Shnlichen Notation angegeben. 

11 Ein Beleg hierfUr sind die formalen Spezifikationen von Netzwerk- 
Protokollen und -Datenformaten in den Internet-RFCs. Diese scheinen mir 
allesamt in der Klasse LL(k) zu liegen. 

12 Bei der Greibach-Normalform miissen alle Produktionsregeln die 
Form X — > aa haben. wobei A' ein Nichtterminalsymbol, a ein Termi- 
nalsymbol, und a eine beliebige Zeichenfolge aus Terminal- oder Nicht- 
terminalsymbolen ist. 
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Eine Schachtelung von DatenformatenWd durch die Un 
terscheidung zwischen Terminal- und Nichtterminalsym- 
bolen ausgedriickt; ein Nichtterminalsymbol lafit sich an 
verschiedenen Stellen wiederverwenden. Eine Sequenz von 
Datenformaten'* wird durch Hintereinander-schreiben von 
Terminal- oder Nichtterminalsymbolen in einer Grammati- 
kregel ausgedriickt; mathematisch gesehen reprasentiert es 
e.n kartesisches Produkt Alternativen zum gleichen Nicht- 
term.nal mussen im Gegensatz zu beliebigen kontextfrei- 
en Grammatikregeln stets durch voneinander verschiedene 
Term.nalsymbole 14 eingeleitet werden, so dass die jeweils 
r.cht.ge Alternative stets am Anfang eines rekursiven Ab- 
sUegs durch einen trivial*, Diskriminator" erkannt werden 

♦k *™ Gegensatz zu Programmiersprachen wird diese Me- 
/"^ ^? SSyStemen vollkoi ™en dynamisch ein- 
gesetzt; die Erkennung eines Datenformats kann iA 
nicht vom Typsystem eines Compilers vorweggenommen 
werden, sondern muss mindestens bei der VerdrahtunRs- 
Operation zur Laufzeit durchfuhrbar sein. Hierfur eig- 
netgch d ie Laujzeit-lnterpretation"> von Datenformaten 
Mm kontextfreier Grammatikregeln ganz besonders 

?««r an te ' 8erUngen durch torObersetzmg von Typ- 
OMffiataken in deterministische Kellerautomaten sind da- 
durch nicht ausgeschlossen 17 . 

Eine konkrete Realisierung mittels interpretierbaren Tvd- 
Grammat.ken konnte beispielsweise folgendermaSen aus- 
senen: 

Nichttenninalsymbole werden durch ASCII 
Ze.chenketten aus GroBbuchstaben und Unterstrich 
dargestellt. Em Beispiel ware „ I P_ADDRESS « 

TerminalsymboUdassen verhalten sich logisch wie Nicht- 
terminale, zu denen keine Regeln definiert werden diirfen, 
da es bereits fest eingebaute Regeln fur sie gibt 18 . Sie wer- 
den durch ASCII-Zeichenketten in Kleinschreibung darge- 
^' d . ene f " ei "| AS Cn-kodierte Zahl angefugt ist, die den 
Platzbedarf m Bytes beschreibt. Beispiele sind „intl» 
„int2\ „xnt4« oder „int8«, die vorzeichen-behaftet 
zujnter pretierende MaschinenwSrter der jeweiligen Lan- 
u «s*««^||e n so || en> odef „ space512 „ fQr eJnen un . nter _ 

i Datenblock. Weitere Terminalsymbolklassen wie 
. — r * dlan - u nsigned_int4« lassen sich spater ie- 
derzeit hinzu erfinden; welche Bedeutung sich hinter dem 
Namen verb.rgt, ist fur das Parsen des Datenformats egal 
nur der Platzbedarf ist entscheidend. ' 

Termhmlsymbole werden durch Hintereinander- 
schreiben einer Terminalsymbolklasse und einer kon- 



fnT 2 t 7 T S h 8 Klammern n0tierL Beis P ie,e si "<* 
m t-- ? » lnt4 ("I)"- Fur Zeichenketten 
vanabler Lange kann man eine K onvention der Art 

ntl^J ' Naa f ' } " einfiihren ' be i der sich der aktuelle 
Platzbedarf aus dem Text zwischen den Hochkommata 
ergibt 

We^SreT ln ,3SSen SiCH beis P ie,SWeise -f folgende 
„ STRUCTURE= int 1 ( 0 ) ; SUBSTRUCTURE ; int4 • » 
Wie zu erkennen ist, werden die Strichpunkte nicht nur 
als Trennzeichen, sondern auch als Abschlusszeichen ei- 
ner Rege! eingesetzt. Die Typgrammatik-Eigenschaft ist 
erfullt, wenn keine zwei Regeln vorhanden sind, die bis 
zum Auftreten des ersten Strichpunktes miteinander iiber- 
einstimmen; weiterhin mussen alle Regeln zum gleichen 
N.chtterminal „ STRUCTURE* hinter dem Gleichheitszei- 
chen mil der -gleichen Terminalsymbolklasse beginnen 
Falls ein N.chtterminal keine Alternativen enthalten soil 

I ^'^ ann iSt 3,8 Sonderfa » ^nes Terminalsymbols 
auch 0 0) zulassig, das einen Diskriminator reprasen- 
tiert, der kemen Platz beansprucht und von dem es deshalb 
nur eine einzige Auspragung gibt (so dass als Folge davon 
keine weiteren Alternativen mehr zulassig sind). 

Fur das Startsymbol der Grammatik kann man eine Kon- 
^n?"^ "f"^ 6 "' beis P ielsw eise ein Nichtterminalsymbol 
„OP fur die Beschreibung von Operations-Nestern, oder 
„DATA" fur die Beschreibung von Datenformaten in persi- 
stenten Nestern. Die Beschreibung der vier Grundoperatio- 
nen sieht dann beispielsweise foIgendermaBen aus: 

OP=string ( ' get ' ) ; int4 ; addr 8 ; int8 ; addr 8 • 
intl ; res_addr8 ; res_int8 ; res_intl ; 

OP=string( 'transfer' ) ; int4; addrS ; intl ; 
intl ; addr8 ; res_intl ; 




( Typische Vertreter von Sequenzen sind Arrays und Records. 
Bei a Igemeinen kontextfreien Grarnmatiken kdnnen Alternativ- 
Regeln .nehrere logische Alternativen reprasentieren. dietogTsche SST 
t,ven zu venMedenen Themen darstellen und nich s to taSwaS 
miteinander zu tun haben brauchen 'ogiscnen Mnne 

pJcSi^T CU1Cht Z B> in de " Ta «* von varia »te» Records von 

x^srsr^ auf: in Ada * *• *«~ ■« 

lfi Dies schlieBt nicht die Verwendung eines Pra-Compilers aus der 

KSST Tei,e der ,n,er — — vo-^:[ 

,7 Ob die Voriibersetzung in ausfOhrbare Maschinenbefehle ( iu« in 
time compiler") weitere Vortei.e bringen kann, ware z unter^uche'n 

"Dteses Konzept taucht in Compilern als Token-Klasse auf z B die 
Token-Klasse aller Identifier Oder aller Zeichenketten 



OP=string ( ' wait ' ) ; i nt 4 ; addrS ; res_intl ; 

OP=string ( ' put ' ) ; int4 ; addr8 ; intl ; 

Dieses Beispiel stellt nur die wichtigsten Grundelemente 
eines Typsystems vor und sollte fur den praktischen Ein- 
satz urn weitere AusdrucksmOglichkeiten erweitert werden 
etwaFeldnamen zur Beschreibung von Records oder wei- 
tere Terminalklassen zur Beschreibung von Bitfeldern oder 
von Bereichstypen, sowie von Ausrichtungs-Konventionen 
(..alignment"). Mit Hilfe weiterer Konventionen ist bei- 
spielsweise die automatisierte Uberprufung der Gultiakeit 
von Adressbereichen oder von Deskriptoren moglich so 
dass diese nicht mehr wie in bisherigen Betriebssystem- 
Implementierungen „von Hand" ad hoc getestet werden 
muss. 
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Zusammenhang mit Objektori- 
entierung 
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ZUSAMMENHANG MIT DEM FUNKTIONALEN PARADIGMA 



59 



Objekt-Instanzen 



Klassen 



Attribute 





Methoden 



Das Bild zeigt den Zusammenhang der vier vorgestellten 
Nest-Arten mit bekannten Konzepten der Objektorientie- 
rung. Die gestrichelten Trennlinien sollen eine Unterteilung 
des Feldes nach zwei verschiedenen Kriterien andeuten: 

• Unterteilung in Objekt-Instanzen und Klassen: Nest- 
Instanz versus zugehoriges Meta-Nest 

• Unterteilung in Attribute und Methoden: Daten-Nest 
versus Operations-Nest 

Die Beziehungen von Instanzen der jeweiligen Nest-Art 
sind durch Pfeile mit Beschriftung der zugehorigen Zu- 
gnffsfunktionen gekennzeichnet. Eine Nest-Instanz steht 
mit ihrer zugehoriger Operations-Nest-Instanz in einer 1:1- 
Beziehung, genau wie beim Zusammenpacken von Attri- 
buten und Methoden in der Objektorientierung zu einer 
Objekt-Instanz. Der Status einer Objekt-Instanz wird dabei 
in der Nest-Instanz abgespeichert. 

Der Zusammenhang mit der Vererbung laBt sich durch 
zwei Anpassungs-Bausteine darstellen, die entsprechen- 
de Transformationen auf den Nestern bzw. Meta-Nestern 
durchfuhren. 



oase_class ^ u 








downcast 




tmp «^^^ 







son_class 



Beim downcast wird die Schnittstelle erweitert; zu den 
am Eingang base_class verfiigbaren Attributen und 
Methoden kdnnen neue hinzukommen, die am Ausgang 
son_class zur Verfugung gestellt werden; ggf. kann da- 
bei auch die Implementierung (bzw. das Verhalten) eini- 
ger Methoden abgeSndert werden (uberschriebene Metho- 
den und virtuelle Methoden). Da sich dabei der Umfang 
des abgespeicherten Status vergroBern kann, ist ein Eingang 
tmp vorgesehen, urn diesen aufzunehmen. Bei geeigneten 
Konventionen iiber die Platz-Aliokation im base_class- 
Nest laBt sich der Status aber auch dort abspeichern, so dass 
tmp uberfliissig wird. 



Beim upcast wird lediglich die Schnittstelle verkleinert 
so dass nicht mehr alle Attribute und Methoden von auBen 19 
zugreifbar sind (Prinzip der Verbergung). 

Aus dieser Beschreibung wird ersichtlich, dass die Kon- 
zepte der Objektorientierung einen Spezialfall der hier vor- 
gestellten Methodik darstellen. Durch die Abstraktionen 
Nest und Baustem sind folgende Konzepte realisierbar, die 
be. ubUchenP Auspragungen von Objektorientierung im 
Regelfall nicht vorgesehen sind: 

• Austausch einzelner Methoden-Implementierungen 
zur Laufzeit, und zwar unabhangig von einer Klassen- 
hterarchie 21 

• Anderung der Representation von Attributen (beim 
Erweitern der Schnittstelle und/oder zurLaufzeitV vol 
Anhang B. s " ' 

• Aufspaltung eines Status-Raums in beliebige Kombi- 
nationen von Teilraumen 22 

• Einfache Verwendung beliebig unterschiedlicher 
Methoden-Satze 23 



6.3 Zusammenhang mit dem Funk- 
tionalen Paradigma 



expr 



tmp 




- f 



son_class 



upcas t 



base_class 



Die Grund.dee eines lambda-Bausteins ist, einen univer- 
sellen Interpreter zu schaffen, dessen tatsachliche Funkti- 
onsweise durch den Inhalt des expr-Eingang in einer ge- 
eigneten Kodierung fest gelegt wird. Am Ausgang f werden 

,JI E!ne ^ erk ! eine .™ n S laBt si <* dadurch erzielen, dass Attribute und Me- 
aufd^T J T lIi8Cn ^-Ncstern »«ht mehrerscheinen. so dass sie 
Z,«Z lT y f m r. geblendet et * chei ™- Bin bessererZ, A .r/p,c/, , r 
dun, daSS b6i der formation auch Lbl^ 
dungen in denjewe.l.gen adjungierten Nestem vorgenommen werden. 

f'Vlf ,St Smal,talk - w ° Methoden-Anderungen oder sogar 
Ktasen-Anderungen zur Laufzeit prinzipiell moglich sind da alle StruT 
turen dynamisch angelegt sind. . 

dus * e hw' e ^'2^°^ Linux ' deren Se,nan <* vom Mo- 
die i^M a T d -' e P,P : 6e6ffnet WunJe - * S ibt Implementierungen. 

Je'S^Jf^l^ T ob > kt °™ntierten Programmiersprachen 
fentl^tt *Zt Seh "\: me gl0baI g0,tige U «terteilung * private und flf- 
* ? T u° r - Dem 8 e 8 enUb « erlaubt das Konzep. der adjungier- 
ten Nester auch S.chten, die fflr jede Teilnehmer-.nstanz Lders ausfcl.en 

steS n™ 0b f^ to n entie " en , Vercrbung Werden Methoden-Schnittstellen 
« *aZZ7 T \f T^'" e ,aSSen hingegen auch *« Verdeckcn bisheri- 
J TTt ^ erM t eth0den »• "hhaltedies fu rsehrnatzIichi wej , ^ 

2TZ^T^T S '^l n einer Baus «'n-Hrerarchie ermoglicht: lo- 
fe »™ £ d6,t eS , S,Ch naCh Ciner Steigerun « AbstraiTtionsstu- 

fe zwar immer noch urn dieselbe Objekt-Instanz. die ZugrifFsmethoden 

o^Z£?f " abS,ra !; ter '' kann Benutzern der hahe^n Ab S 
™„S UnterS K agen '. d,esemit Meth °"en niedrigerer Stufe gemischt zu 
verwenden, um be.sp.ekwe.se die Umgehung von e^t wei.er oben gege- 
benen Zxwdusrungen zu unterbinden („schwarze SchnitLstellen") 
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besondere generische Operationen zur Verfugung gestellt, 
die iiber die gestrichelt gezeichneten Leitungen vom nach- 
folgend vorgestellten apply verwendet werden konnen: 
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apply 

















tmp 



f (x) 



Eine von lambda erzeugte Funktion stellt keine vollstan- 
dige Space-Instanz mit einem Zustand dar, sondern stellt le- 
diglich die Operationen bereit, die die Funktion f realisie- 
ren, wenn sie mit Hilfe von apply und einem Argument 
x zu einer funktionsfahigen Nest-Instanz f (x) verknupft 
werden. Da dabei zusatzlich zum in x gehaltenen Status 
weiterer Platzbedarf fur Status-Information zur Berchnung 
von f (x) erforderlich sein kann, wird wie fur solche Falle 
uJajflkgin tmp-Eingang vorgesehen. 

|unktionsweise ist wie folgt skizziert: wenn am 
;f (x) irgendwelche Nest-Operationen aufgerufen 
weroen, dann ruft apply die generischen Operationen des 
f-Eingangs mit den passenden Daten- Argumenten auf, die 
es vorher aus x gewonnen hat (und ubergibt ggf. weiteren 
aus tmp gewonnenen Hilfsspeicher, der Instanz-spezifisch 
ist). 

Funktionen hoherer Ordnung [Fie88] lassen sich nach 
dem gleichen Prinzip erzeugen. Am Ausgang von apply 
erscheinen dabei lediglich keine voll funktionsfahigen Ne- 
ster, sondern nur Operations-Nester, die mit Hilfe weiterer 
apply-Instanzen erst normal benutzbare Nester ergeben. 

Bausteine und ihre Verdrahtungen .sind fur sich genom- 
men bereits universelle Konstrukte, die sich beispielsweise 
auch mit theoretisch interessanten Beschreibungen wie den 
Hotz'schen X-Kategorien beschreiben lassen. 

Weiterhin ist zu erwahnen, dass man rein theoretisch be- 
kannte^erfahren zur Term- oder Graph-Red uktion auch 
Vschaltbausteine in den Steuerleitungen von con- 
">bschnitt 4.2.1) realisieren konnte. Theoretisch 
kl^l^han damit auch rein syntaktische Evaluationen mit 
Hilfe in den Baustein-Verdahtungen gespeicherten Bezie- 
hungen betreiben, ohne den Zustand der beteiligten Ne- 
ster benutzen zu miissen. Die Baustein-Verdrahtungen wer- 
den dabei zur Representation einer algebraischen Struktur 
missbraucht. Dieser theoretische Zusammenhang beleuch- 
tet jedoch die Wichtigkeit und Notwendigkeit, in der Praxis 
sehr auf die in den Verdrahtungen gespeicherte Information 
und auf ihre nicht immer Ieicht zu beherrschenden Konse- 
quenzen zu achten. 

Obwohl man in der Praxis den hier aufgezeigten Zu- 
sammenhang mit funktionalen Paradigmen eher nicht in 
der theoretischen Form des allgemeinen Lambda- Kalkii Is 
einsetzen sollte (da Nester nicht als Konkurrenz zu eta- 
blierten Laufzeitsystemen fur funktionale Berechnungen 
konstruiert wurden), durften speziellere Formen funktiona- 
Ier Denk- und Konstruktionsmethoden durchaus wertvolle 
praktische Anwendungen haben. Universell einsetzbare In- 
terpreter brauchen nicht unbedingt pure funktionale Para- 



digmen zu beachten, sondern konnen in der Praxis durch- 
aus ,,hemdsarmelig" wie beispielsweise durch einen Perl- 
Interpreter [HajOO] realisiert werden, der seinen Programm- 
code aus einem Eingang bezieht, der von den zu bearbeiten- 
den Daten getrennt ist 24 . Damit lassen ich beispielsweise 
Prototypen sehr schnell entwickeln. 

6.4 Zusammenhang mit Datenbank- 
Schemata 

Relational Datenbank-Schemata lassen sich mittels Ne- 
stern und Bausteinen erzeugen, umwandeln, in Datenbank- 
Instanzen umsetzen, und die instantiierten Daten verarbei- 
ten. 



schema m m B 



tmp 




table 



In einem Nest lassen sich Datenbank-Tabellen und Indi- 
zes ablegen, das zugehSrige (Teil-)Schema wird im Meta- 
Space bzw in den Attributen in einer geeigneten Represen- 
tation gehalten. Durch einen Baustein gen_table kann ein 
reines Schema, das ein oder mehrere Metabeschreibungen 
von Tabellen enthalt, in ein oder mehrere 25 entsprechende 
Tabellen instantiiert werden. Der persistente Status wird im 
tmp-Eingang.gehalten und am Ausgang zur Verfugung ge- 
stellt. Es wird dafiir gesorgt und gepruft, dass die instan- 
tiierten Datensatze sowohl syntaktisch als auch semantisch 
dem Schema- Aufbau entsprechen. 

Datensatze fester Lange lassen sich am einfachsten als 
zusammenhangendes Array abspeichern. In diesem Fall 
braucht das adjungierte Nest nicht unbedingt die Grenzen 
jedes einzelnen Datensatzes darzustellen, da diese Informa- 
tion leicht berechnet werden kann. Bei variabler Datensatz- 
Lange ist allerdings die Representation luckenlos liegen- 
der Pakete (vgl. Abschnitt 3.4.1) im adjungierten Nest an- 
gebracht. Falls aus Grunden der Uniformitat diese Art der 
Darstellung auch bei festen Datensatzlangen gefordert wird, 
laBt sich der Inhalt des adjungierten Nestes intern auf vir- 
tuelle Weise berechnen, ohne Platz im persistenten Spei- 
cher zu verbrauchen. Eine weitere Moglichkeit besteht dar- 
in, die Bestandteile von Datensatzen mit fester Lange von 
denjenigen mit variabler Lange zu trennen, so dass eine per- 
formante Array-Darstellung der Datensatze mit Verweisen 
auf einen Heap-Bereich entsteht, der die variablen Teile be- 
herbergt; derartige Verweise entsprechen konzeptionell den 
Datensatz-Beschreibungen im adjungierten Nest und soli- 
ten aus Grunden der Uniformitat an einer Stelle zentrali- 
siert werden; das Konzept des adjungierten Nestes eignet 

24 Ein klassiches Beispiel universeller Jnterpreter-Konstrukte h5herer 
Ordnung ist der#!-Operator zusammen mit der ArgumentUbergabe an Pro- 
zesse in Unix, mit dem sich beliebige Interpreter starten lassen, die ihrer- 
seits wieder beliebige weitere Operationen auf beliebigen Daten ausfuhren 
kdnnen. Eine Nachbildung durch Bausteine ist Ieicht mdglich. 

-Mehrere Tabellen, Indizes etc. sollten sich durch Vorreservierung 
genUgend grosser Adressbereiche aus mindestens 64 Bit Adressraum- 
Gesamtgr6Be herausschneiden lassen, so dass Verschiebungen ganzer Ta- 
bellen gar nicht oder nur extrem selten benStigt werden. 
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m 

m eine 



sich hierfur besonders 26 . Urn iSffie gute Kombinierbarkeit 
von Bausteinen zu erhalten, sollten diese Konventionen ein- 
heitlich festgelegt werden. 



table 



tmp 
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gen_index 









i ndexed_ babl € 



Uber die Sortierung von Datensatzen wurde bisher nichts 
gesagt. Es ist moglich, eine Tabelle gleich von vornherein 
nach einem Primarschliissel sortiert zu halten. Da Sekun- 
darschlussel jedoch unabhangige Sichten erlauben, ist es 
giinstig, die Schlussel unabhangig von ihrer Art und Anzahl 
ebenfalls im Nest zu halten. Eine Schlussel-Reprasentation 
kann beispielsweise als Array von Index-Nummern der Da- 
tensatze erfolgen, die nach dem Schlussel sortiert sind. Ein- 
fugungen und Loschungen von Datensatzen werden dann 
durch move-Operationen auf den jeweiligen Arrays be- 
werkstelligt Naturlich ist es ebenfalls moglich, klassische 
Reprasentationen wie B + -Baume zu verwenden, doch sind 
diese wesentlich komplizierter aufgebaut und schwerer zu 
interpretieren. Da Nester vorzugsweise universelle Gene- 
rizitat mittels sehr einfacher Datenstrukturen reprasentie- 
ren sollten, halte ich die Verwendung sortierter Arrays fur 
gunstiger, zumal eine billige move-Operation zur Verwal- 
tung dieser Array-Strukturen zur Verfugung steht. Perfor- 
mante Suchstrukturen wie B-Baume werden dadurch nicht 
uberfliissig; sie werden lediglich an anderer Stelle einer 
Baustein-Hierarchie eingesetzt, namlich bei der Erzeugung 
dy namischer Nester (Baustein map in Abschnitt 4. 1 .3). 

i 



tablel mmm ^ m 








join 




table 2 m 







product 



-Die Operationen der Relationen- Algebra wie Selektion, 
Projektion und Kartesische Produktbildung durch verschie- 
dene join-Varianten lassen sich direkt durch Bausteine 
darstellen und ausfiihren. Details werden weiteren Arbeiten 
zur Integration von Datenbanken in Betriebssysteme iiber- 
lassen. 



26 Eventuel! wflrees eine gute Idee, adjungierte Nester zum adjungierten 
Nest einzufQhren. Das adjungiert-adjungierte Nest enthait dann die Be- 
schreibung ganzer Tabellen und Indizes, das einfach adjungierte Nest die 
konkrete Beschreibung der jeweiligen Tabelle. 
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Kapitel 7 



Multiversion-Modelle 



In diesem Kapitel soli untersucht werden, wie sich die 
Funktionalitat von Transaktionen auf einfache generische 
Weise in die Nest-Schnittstelle integrieren lasst. Ziel ist 
nicht die vollstandige Abdeckung aller nur denkbarer mul - 
tiversion-Modelle, sondern die exemplarische Aus- 
wahl und Darstellung einiger (hoffendich) fur praktische 
Zwecke geeigneter Modelle, die hinsichtlich der gangig- 
stei^ransaktions-Semantiken universelle Generizitat bereit 
^ fc|ollten. 

WJ^P risch betra chtet hatten Transaktionen [BHG87, 
I^^GR93, Elmbe] das Ziel, trotz paralleler Aktivita- 
ten jedem Konsumenten ein singleuser-Modell bereit 
zu stellen, so dass sich Program mierer nicht urn Paralle- 
litat zu kummern brauchten. Nach ausfuhrlicher Untersu- 
chung von Synchronisation und Riicksetzen (recovery) wur- 
de entdeckt, dass man trotz singleuser-Ausgangsbasis 
mit Versionen von Datenobjekten zu tun hatte; ohne Ver- 
sionierung ist Riicksetzen nicht denkbar. Daraufhin wur- 
den Multiversions-Varianten von Transaktionen [VGH93] 
untersucht, insbesondere Zeitstempel-Verfahren auf Basis 
von Versionen (time stamp ordering, time domain addres- 
sing). Im Folgenden setze ich die Kenntnis der wesentlichen 
Grundkonzepte aus der Datenbank-Welt aus der genannten 
Literatur beim Leser voraus. 

Fur unsere Zwecke sind generische Transaktions- 
Mechanismen an der Nest-Schnittstelle gefragt, mit denen 
m^afi&s^tt universell verschiedene Transaktions-Modelle 
tegie durch Bausteine implementierbar sind. 




7.1 Anforderungen 

In Anwendungsbereichen wie z.B. Finanzbuchhaltung gibt 
es gesetzliche Anforderungen, die das spatere Nachvoll- 
ziehen (Lesen) aller durchgefuhrten Aktionen (Operatio- 
nen) in der zeitlichen Reihenfolge der Durchfuhrung er- 
zwingen (lUckenlose zeitliche Dokumentation aller Opera- 
tionen). Daruber hinaus existieren davon unabhangige sack- 
liche Kriterien als zeitliche Ordnungsmerkmale, unter de- 
nen durchgefuhrte Operationen ebenfalls nachtraglich zu- 
greifbar sein miissen. Ein typisches Beispiel aus der Fi- 
nanzbuchhaltung ist der Unterschied zwischen dem Beleg- 
Datum eines Belegs und dem Verbuchungs-Datum: die Rei- 
henfolge der Verbuchung (Eintragung) von Belegen muss 
nicht notwendigerweise in der Reihenfolge ihrer Geltung 
(Beleg-Datum) erfolgen. Im Journal einer Finanzbuchhal- 
tung miissen alle Eintrage mindestens in der Reihenfolge 



der Eingabe, in den Konto-Auszugen sollten sie zusatzlich 
in der Reihenfolge ihrer sachlichen Geltung abrufbar sein. 
Diese Anforderungen lassen sich auf folgende Weise ver- 
allgemeinern: 

Jede jemals durchgefuhrte Operations-Instanz auf ei- 
nem Nest muss anhand eines Merkmals (z.B. Zeit- 
stempel) wieder eindeutig auffindbar sein 



1. 



2. Es konnen mehrere von einander unabhangige Zeit- 
Bereiche notwendig sein 

Punkt 1 bedeutet, dass ein „Elefantengedachtnis 1 " imple- 
mentierbar sein muss, da es Anwendungen gibt, die die- 
ses aufgrund gesetzlicher Anforderungen verlangen. Falls 
bei anderen Anwendungen der Overhead stort, lassen sich 
eingeschrankte Modelle ableiten, bei denen nicht mehr be- 
notigte Informationen gezielt oder automatisch „vergessen" 
werden. 

Punkt 2 scheint auf den ersten Blick zu bedeuten, dass 
aufgrund gesetzlicher oder sachlicher Anforderungen ein 
oder mehrere Totalordnungen auf ein oder mehreren Zeit- 
Bereichen zu implementieren waren. Dies ware jedoch ins- 
besondere in verteilten Systemen sehr hinderlich. Die fol- 
genden Uberlegungen befassen sich hauptsachlich mit die- 
sem Problem. 

1.2 Allgemeines Modell 

Eine Moglichkeit ware die Einfuhrung von zeitlichen 
Halbordnungs-Konzepten in die Nest-Schnittstelle. Eine 
Totalordnung wurde sich dann als SpezialfaH dort ergeben, 
wo dies aufgrund von Anforderungen notwendig ware. Die- 
se Moglichkeit wird hier aufgrund ihrer hohen Komplexitat 
nicht weiter untersucht 2 . Stattdessen schlage ich folgende 
Betrachtungsweise des Problems vor: 

Die Idee der Festlegung einer zeitlichen Totalordnung 
zwischen Operations-Instanzen impliziert nicht notwendi- 
gerweise, dass der Festlegungs-Vorgang selbst in totalge- 
ordneter zeitlicher Reihenfolge geschehen muss. Es wird 
lediglich verlangt, dass das Endergebnis eine zeitliche To- 
talordnung ergeben muss; wann dieses Endergebnis jedoch 
berechnet wird, ist eine andere Frage. 

1 Bekannte Realisierungen sind z.B. die Logs von Datenbanken. die ge- 
legentlich vollstandig aufbewahrt werden und als SQL-Tabelle dargestellt 
werden, so dass man in ihnen wie in anderen Tabellen suchen kann. 

2 KonzeptuelI ware dies die Verwendung Lamporlscher Uhren [Lam78] 
auch in persistenten Speichern als dauerhaftes Modell der Darstellung zeit- 
licher Relationen zwischen Operationen. 
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7.3- ZEITINTERVALL-MODELL 



♦ 

'ischen i 





Diese Unterscheidung zwischen virtueller Zeit und realer 
Reihenfolge von Operations-Ausfiihrungen konnte als la- 
zy evaluation bei der Festlegung der zeitlichen Reihenfolge 
von Operations-Instanzen charakterisiert werden 3 . Solange 
eine Totalordnung noch nicht endgultig festgelegt worden 
ist, konnen (temporare) Halbordnungen im Effekt vorkom- 
men. Einmal gemachte Festlegungen lassen sich jedoch nie 
mehr revidieren; dies ist nichts anderes als die konsequen- 
te Anwendungdes Persistenz-Gedankens auf die zeitlichen 
Ordnungsrelationen. Ansonsten ist Persistenz jedoch unab- 
hangig von den erreichten Zwischen- oder Endzustanden ei- 
nes Nestes. 

Der Endzustand eines Nestes ist erst dann erreicht, wenn 
nicht nur die Daten-Inhalte und Parameter aller ausgefiihr- 
ten Operations-Instanzen, sondern auch die Zeitstempel der 
Operations-Instanzen intern fest gelegt sind. Konsumenten 
erhalten niemals Kenntnis von halb-geordneten Zwischen- 
zustanden; spatestens die Abfrage zeitlicher Relationen an 
der Nest-Schnittstelle fuhrt automatisch zu einer Festlegung 
(und damiteventuell zu einer Zustands-Anderung im stren- 
gen Sinn, selbst bei einer „simplen" Abfrage). 

Die nahere Festlegung vorher (teilweise) unbestimm- 
ter zeitlicher Relationen wird Prazisierung genannt; alle 
zeitlichen Relationen zwischen Operationen eines Nestes 
werden zusammen gefasst Prazisierungs-Zustand genannt. 
Prazisierungs-Zustande mussen /consistent sein, d.h. bei ei- 
nem verteilten System diirfen zwei verschiedene Abfrager 
keine widerspruchlichen Antworten zum gleichen Sachver- 
halt bekommen. Die Menge aller ausgefuhrten Operationen 
samt deren Parameters jedoch ohne die zeitlichen Relatio- 
nen, wird Daten-Zustand eines Nestes genannt. 

Parallelitat von Operationen ist insbesondere dann 
moglich, wenn keine Abfrage zeitlicher Relationen des 
Prazisierungs-Zustandes erfolgt (etwa weil zeitliche Ord- 
nungen fur das zu losende Problem keine Rolle spielen). 
Fails niemals eine Abfrage zeitlicher Relationen zwischen 
Operations-Instanzen stattflndet, dann kann ein persisten- 
ter Speicher im Extremfall lauter unkorrelierte Operations- 
Instanzen enthalten, deren zeitliche Reihenfolge nicht fest- 
gelegt ist (eine Festlegung darf in diesem Fall naturlich 
trotzdem erfolgen). 

Ob zwei Operations-Instanzen eine zeitliche Relation 
zu einander besitzen, konnte mit Hilfe eines Benutzungs- 
Modetls implizit fest gelegt werden. Beispielsweise k6nn- 
te ein bestimmtes Benutzungs-Modell vorschreiben, dass 
samtliche Operationen, die sich auf gegenseitig iiberlap- 
pende Adressbereiche eines Nestes beziehen, in eine To- 
talordnung gebracht werden mussen. Es sind jedoch Fal- 
le denkbar, in denen selbst diese schwach erscheinen- 
de Forderung nicht erfullt zu sein braucht (beispielswei- 
se wenn irrelevante Operations-Durchfuhrungen einfach 
ignoriert und niemals mehr betrachtet werden). Da weiter- 
hin sehr viele verschiedene Benutzungs-Modelle denkbar 
sind, schlage ich vor, keine Annahmen iiber implizite Ab- 

*Beim Time-Warp [Jef85] wird zwar ebenfalls eine virtuelle Zeit- 
Achse verwendet, doch schreiten die Operations-Auflihrungen auf dieser 
Achse monoton vorwarts und werden nur beim Rollback gelegentlich in- 
tern zurfickgesetzt. Im Unterschied dazu erlaubt das hier propagierte Mo- 
dell behebige ROckdatierungen von Operationen. die unabhangig von evtl 
vorkommenden Rollbacks sind; weiterhin wird die virtuelle Zeit-Achse 
nut der Orts-Achse zu einer zweidimensionalen Ebene verknUpft 
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hangigkeiten zwischen Operations-Instanzen in die Nest 
Schnittstelle aufzunehmen, sondern jegliche zeitliche Ab- 
hangigkeiten explizit zu machen. Die Realisierun* unter- 
schiedhcher Benutzungs-Modelle wird dadurch zur°Auf-a- 
be konkreter Baustein-Implementierungen. 

Das allgemeinste mul tivers ion-Model I sieht so aus 
daB zu jeder durchzufiihrenden Operations-Instanz in ir- 
gend einer Form angegeben werden muB, von welchen an- 
deren („fruheren ,< ) Operations-Instanzen sie abhan^t Die 
Spezifikation der „friiheren" Operations-Instanzen braucht 
keine indi viduelle Bekanntschaft aller in Frage kommenden 
Operations-Instanzen voraus zu setzen, sondern kann durch 
verschiedene mengen- oder pradikatenorientierte Speziflka- 
tionsmechanismen erfolgen. 

Aus der Vielzahl von Spezifikationsmechanismen fur 
zeitliche Ordnungen wahle ich im Folgenden eine bestimm- 
te aus und uberlasse die Untersuchung alternativer Mecha- 
nismen weiteren Forschungsarbeiten. 

7.3 Zeitintervall-ModeU 

Die Grundidee besteht darin, als Zeitbasis eine phrsikali- 
sche Lamportsche Uhr [Lam78] mit genugender Genau- 
lgkeit zu verwenden, jedoch den einzelnen Operations- 
Instanzen keine festen Zelt-Punkte, sondern Zeit-Intewalle 
(vgl. Begnff der Linearisierbarkeit in [HW90]) zuzuord- 
nen. Im Unterschied zu festgefugten Konsistenzmodellen 
wiq der hnearen Konsistenz, die Halbordnungen auch im 
Endergebnis zulassen, konrieri Zeitstempel-Intervalle zu je- 
dem beliebigen spateren Zeitpunkt nachtraglich verkleinert 
(Spezialfall einer Prazisierung) werden: ein urspriinglicher 
Zeitstempel [t u t 2 ] mit t x < t 2 lasst sich jederzeit in*[f 3 , t 4 ] 
mit t x < i 3 , t 3 < t 4 und t A < t 2 umwandeln. 

Eine solche Verkleinerung muss immer dann durchge- 
fuhrt werden, wenn sich beim Vergleich der Zeitstem- 
pel zweier Operations-Instanzen o Pl und op 2 , geschrieben 
*WPi) = [t u h] und t( op2 ) = [t 3y t 4 ], eine gegensei- 
tige Uberlappung (d.h. t 3 < t 2 A t x < U oder f* < 
U A t 3 < h) ergibt. Durch die erzwungene Verkleinerungs- 
Operation wird sicher gestellt, dass anschliessend entwe- 
der t 2 < t 3 oder t A < t x gilt 5 , d.h. eine Kommutation der 
beiden Operations-Instanzen ist anschliessend nicht mehr 
moglich. Solange die Zeitstempel der beiden Operations- 
Instanzen nicht durch eine implizit oder explizit ausgefuhrte 
Vergleichs-Operation miteinander verglichen werden. dur- 
fen sich die Intervalle uberschneiden, d.h. es braucht keine 
endgultige Festlegung der Reihenfolge der beiden Opera- 
tionen zu erfolgen. 

Fur den Benutzer dieses Modells sieht alles so aus. als 
gabe es eine totalgeordnete globale ZeiL Die interne Reali- 
sierung verwendet jedoch (temporare) Halbordnungen. Die 

4 Es geht auch mit logischen Lamportschen Uhren, nur muss der Konsu- 
ment dann die ,.Bedeutung«* von Zeit-Werten in der Real-Zeit auf miihsame 
Weise selbst bestimmen. 

^Bei dieser Darstellung wird stiU-schweigend voraus gesetzt. daB Mets 
eindeutige Zeitstempel in einem verteilten System generiert werden. Eine 
wohlbekannte Methode hierfilr ist das Anhangen von Knoten-Kennzeichen 
an den abgelesenen Wert einer Rechner-Uhr. so daB eventuell gleichlau- 
tende Uhrzeiten. die durch zufalliges „gleichzeitiges" Ablesen von Uhren 
entstehen konnten, stets zu eindeutigen Zeit-Werten fUhrt. 
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Presentation als Totalordnung nach aussen unterscheidet 
dieses Modell von explizit auf Halbordnungen aufgebauten 
Model len. 



7.4 Container-Operationen: Locks 

Bereits im multiuser-Modell (Abschnitt 3.3.5) dienten 
Locks zur Klammerung einer Menge von Zugriffs- 
Operafionen. In multiversion-Modellen werden Lock- 
Operationen analog dazu als zeitliche und raumliche Con- 
tainer aufgefasst, die eine Menge von Zugriffs-Operationen 
beherbergen konnen. Die Idee besteht darin, nur noch 
diese Container als Einheiten fur Beziehungen zwischen 
Zugriffs-Operationen zu verwenden, und von den De- 
tails der im Container beherbergten Operationen und 
Operations-Arten zu abstrahieren. 

Lock-Operations-Instanzen werden als persistente oder 
quasi-persistente 6 Objekte aufgefasst, die eine zeitliche und 
eine ortliche Dimension besitzen und einem Mandat als 
Eigent umer zugeordnet sind; verschiedene Transaktionen 
unter verschiedenen Mandaten laufen. Die ortli- 
Jdehnung ist der Bereich des virtuellen Adressraums 
stes, auf den sich der Lock bezieht. Die zeitliche 
Ausdehnung entspricht den soeben vorgestellten Interval- 
len auf einer virtuellen Zeitaclise* die unabhangig von der 
tatsachlichen Ausfiihrungs-Reihenfolge besteht. Wahrend 
die ortliche Ausdehnung weitgehend festgelegt ist (nach- 
dem sie z.B. einmal als spekulative Locks ausgehandelt 
wurden, vgl. Abschnitt 5.3), kann die zeitliche Ausdeh- 
nung nachtraglich jederzeit verkleinert werden (Prazisie- 
rung). Ein Container darf nur solche Zugriffs-Operationen 
beherbergen, die sich auf einen Teil-Bereich ddr raumlichen 
und zeitlichen Dimension beziehen, Im Regelfall erben die 
von einem Container beherbergten Zugriffs-Operationen ih- 
re zeitliche Dimension vom umgebenden Container. 

Im folgenden Bild werden Write-Lock-Instanzen durch 
Rechtecke mit spitzen Ecken, Read-Lock-Instanzen dage- 
gen durch abgerundete Ecken dargestellt: 





h: 



Zeit 



Mit Quasi-Persistenz ist gemeint, dass grundsatzlich die Persistenz 
zwar angesprebt wird, jedoch spa'ter die gespeicherte Information durch 
gezieltes Vergessen vergrSbert werden kann. 
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SION-MODELLE 



Verschiedene Write-Lock-Instanzen durfen sich niemals 
gegenseitig uberlappen, d.h. nicht die gleiche Flache in der 
zeitlichen und ortlichen Dimension einnehmen. Im Kon- 
fliktfall lassen sich Write-Locks jedoch nachtraglich immer 
so verkleinern, dass sie auf der Zeit-Achse nebeneinander 
passen (aufgrund der eindeutigen Zeitstempel, siehe Ab- 
schnitt 7.3). Read-Lock-Instanzen durfen sich dagegen ge- 
genseitig uberlappen. 

Die Verhaltnisse zwischen Read- und Write-Lock- 
Instanzen werden im folgenden Bild naher untersucht: 

Ort 




Zeit 

Die in den Kastchen eingezeichneten Nummern sollen die 
Reihenfolge 7 andeuten, in denen die jeweiligen Locks ge- 
setzt werden sollen. Das Setzen des gestrichelt gezeichne- 
ten Locks 3 ist nicht moglich, weil er die durch gestrichelte 
Linien angedeutete „Sicht" des vorher dagewesenen Locks 
2 auf Lock 1 teilweise „verdecken" wurde. Falls die Rei- 
henfolge von Lock 2 und 3 vertauscht wurde, dann ware 
ein Setzen aller drei Locks moglich, jedoch wurde dann die 
Read-Lock-Instanz eine Sicht auf die kleinere Write-Lock- 
Instanz erhalten. Im folgenden Sonderfall ist eine Konflikt- 
losung durch nach tragi iches Verkleinern moglich: 



Ort 
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Zeit 

Es gilt folgender Grundsatz: Eine einmal gewahrte (bzw. 
in Anspruch genommene 8 ) Sicht eines Locks auf andere 
Locks darf nachtraglich nicht verandert werden. 

Die Frage ist, was man unter einer Sicht auf andere Locks 
verstehen soil. Intuitiv geht es urn die bekannte Seman- 
tik von Speichern, nach der eine Lese-Operation bzw. ein 

7 Das Konzept einer ..globalen Reihenfolge" von Operations- 
Aussfuhrungen braucht in einem verteilten System nicht verwendet 
zu werden. Die Darstellung durch Reihenfolge-Nummern dient hier nur 
zur Illustration. 

x Es sind allgemeinere Modelle denkbar, bei denen es nicht auf die 
Sichten zwischen Locks, sondern zwischen den darin enthaltenen Zugriffs- 
Operationen ankommt. Solange im Beispiel nur Lock 2 gesetzt f aber nicht 
gelesen wurde, konnte man Lock 3 noch gewahren. Das sich daraus erge- 
bende kompiziertere Modell wird in dieser Arbeit nicht untersucht. 
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Read-Lock den Zustand dtr^itlich letzten davor liegen- 
den Anderung (Write-Lock bzw. Schreib-Operationen) se- 
hen sollte. Der Unterschied zur klassischen Semantik be- 
steht lediglich darin, dass die Zeitachse ein virtuelles Ge- 
bilde ist,. auf dem die Relationen „vorher" und „nachher <4 
unabhangig von der tatsachlichen Ausfuhrungsreihenfolge 
festgestellt werden (sofern eine global eindeutige Ausfuh- 
rungsreihenfolge uberhaupt existiert). 



7.5 Kausale Abhangigkeiten 

Die Verallgemeinerung der Idee einer Sicht einer Lock- 
Instanz auf andere Lock-Instanzen wird direkte kausale Ab- 
hangigkeit genannt. Die Verallgemeinerung besteht darin, 
dass nicht nur Abhangigkeiten wegen der (moglichen) Sicht 
auf andere Lock-Instanzen gleicher Adressbereiche als kau- 
sale Abhangigkeit gewertet werden, sondern dariiber hin- 
aus noch beliebige weitere kausale Abhangigkeiten in das 
(quasi-)persistente Prazisierungs-Zustands-Modell auf ex- 
plizite Anforderung aufgenommen werden konnen. 

Eine typische Anwendung fur die Aufnahme extern 
spezifizierter kausaler Abhangigkeiten ist die Herbrand- 
Semantik klassischer Transaktionen [VGH93]. Klassische 
„an der Syntax" orientierte Transaktionen betrachten je- 
de Schreiboperation als kausal abhangig von alien vorher 
durch die selbe Transaktion gelesenen Objekten. Sogenann- 
te „semantische" Transaktions-Modelle [Elmbe] versuchen 
dagegen, durch Kenntnisse iiber den inneren Aufbau der 
Transaktionen nur diejenigen kausalen Abhangigkeiten als 
Konsistenz-Kriterium in Betracht zu Ziehen, die auch tat- 
sachlich vorhanden sind und benutzt werden. 

Wir stellen universelle Generizitat bezuglich verschie- 
dener Transaktions-Modelle dadurch her, dass wir die 
explizite Angabe kausaler Abhangigkeiten in der Nest- 
Schnittstelle verlangen. Der Sonderfall vollstandiger kau- 
saler Abhangigkeiten von alien je von einer Transaktion an- 
gefassten Objekte lasst sich relativ leicht als Strategic durch 
einen geeigneten Anpassungs-Baustein implementieren. 

Konkret lasst sich dies so gestalten: Read-Lock- 
Instanzen erhalfen automatisch eine direkte kausale Abhan- 
gigkeit von alien Write-Lock-Instanzen, die sich mit ihrem 
Ausschnitt aus dem Adressbereich uberschneiden und die 
in der Zeitachse davor am nachsten liegen. 

Bei Write-Lock-Instanzen muss der Aufrufer der Write- 
Lock-Operation eine Menge von Adressbereichen angeben. 
Aus dieser Menge von Adressbereichen wird die Menge der 
zeitlich nachstliegenden Write-Lock-Instanzen bestimmt, 
von denen eine direkte kausale Abhangigkeit angenommen 
werden soil. Diese Art der Abhangigkeit dient lediglich 
als Informationsubergabefurzusatzliche Bedingungen oder 
Eigenschaften wie beispielsweise die Serialisierbarkeit, de- 
ren Einhaltung eine Frage konkreter Implementierungs- 
Strategien ist. Die folgende Situation lasst sich beispiels- 
weise auf verschiedene Arten losen: 
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In der Ausgangs-Situation wurde Lock 3 als kausal abhan- 
gig von Lock 1 und Lock 2 definiert. Der neu hinzukom- 
mende Lock 4 uberschneidet nur den Adressbereich von 
Lock 1, nicht jedoch den von Lock 3. Da er nicht gleich- 
zeitig die Adressbereiche von Lock 3 und 2 uberscheidet 
ist die Zulassigkeit dieser Operation eine Frage der konkre- 
ten Strategic Ich sehe folgende Moglichkeiten: 

Man kann die Ausgangssituation (erstes Bild) zulassen. 
Dann muss jedoch persistent gemerkt werden, von wel- 
cher Version (namlich Lock 1) die konkrete kausale Ab- 
hangigkeit besteht. Andernfalls wurde eine Verkleinerun» 
von Lock 4 wie im zweiten Bild zu einem unbeabsiclv 
tigen Wechsel der Version fuhren, von der die kausale 
Abhangikeit besteht. Letzteres Problem konnte auch da- 
durch vermieden werden, dass man unerwunschte Versions- 
Anderungen vermeidet, indem derartige Locks nicht gesetzt 
werden diirfen. Die spezielle Ausgangssituation lasst hier- 
fur zwar wegen der zeitlichen Uberschneidung von Lock 4 
mit Lock 3 auch die spezielle Losung aus dem dritten Bild 
zu, doch fuhrt dies im allgemeinen zu einer Behinderung. 

Der einfachste Losung scheint mir zu sein, „iibersprin- 
gende" kausale Abhangigkeiten 9 zuzulassen, die auf den 
jeweihgen Lock-Instanzen und nicht auf den Adressberei- 
chen aufgebaut sind. Uberspringen ist dann zugelassen, 
wenn sich beide Adressbereiche von Quelle und Ziel der 
direkten kausalen Abhangigkeit nicht mit dem Adressbe- 
reich der eingeschobenen Lock-Instanz uberschneiden. Es 
konnen jedoch weitere Zusatzbedingungen fur die Zulas- 
sigkeit solcher „uberspringender" kausaler Abhangigkeiten 
als besondere Strategie eingefuhrt werden; hierzu zahlt ins- 
besondere die Einhaltung der Serial isierbarkeit von Trans- 
aktionen. 



7.6 Aktualitatsgrade 

Der aufmerksame Leser wird sich bereits gefragt haben, wie 
unlock-Operationen in einem Model! funktionieren sol- 
len, das alle Lock-Instanzen als (quasi-)persistente Objekte 
auffasst und sie im Extremfall fur immer aufbewahren kann 
(womit z.B. in militarischen oder geheimdienstlichen An- 
wendungenjederzeit nachvollziehbar ware, wer wann wel- 
che Read-Locks gesetzt und die zugehorigen Daten inspi- 
ziert hat). 

Die als Container fUr Zugriffs-Operationen wirkenden 
Lock-Instanzen mussen irgendwann abgeschlossen werden. 
AbschlieBen bedeutet, dass der Container keine (nachtras- 
Iich angelieferten) Operationen mehr fur die Beherbergun* 
akzeptiert. . " " 

Beim Anlegen wird jedem Container ein Mandat oder ei- 
ne Menge von Mandate n als „Eigentiimer" des Containers 

9 Dies ist ahnlich zu nicht-determinanten Zustands- Abhangigkeiten aus 
Abschmtt 3.2, bezieht sich jedoch nicht auf die ZustSnde selbst. sondern 
auf die in den Zustfinden gespeicherten kausalen Abhangigkeiten 
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zugeordnet. Der Zustand eines Container^vird beim Anle- 
gen ebenfalls festgelegt, kann jedoch spater geandert wer- 
den und ist ein Wert aus der folgenden hierarchisch geord- 
neten Aufzahlung von Aktualitatsgraden: 

act_invalid Der Container beherbergt ungultige (d.h. 
zu ignorierende) Operationen. 

act_destroyable Der Container beherbergt ein vor- 
laufiges Berechnungsergebnis, das jederzeit 
(evtl. asynchron) auch durch fremde Mandate 
(nicht nur durch das Eigentumer-Mandat) fur 
ungultig erklart werden kann, ohne dass da- 
durch ein irreparabler Schaden entsteht 

act_optimistic Der Container beherbergt eine vor- 
laufige Version, deren Gultigkeit noch nicht 
feststeht. Eine Ungultigkeits-Erklarung kann 
jedoch nur durch das Eigentumer-Mandat er- 
folgen (vgl. optimistische Strategien in der 
Datenbank-Literatur [VGH93]). 

Es handelt sich um einen vorlaufigen (noch 
nicht abgeschlossenen) Container, zu dem je- 
derzeit neue Operationen zur Beherbergung 
hinzukommen konnen. Ein Entzug bereits be- 
herbergter Operationen ist im Normalfall nicht 
vorgesehen (einzige Ausnahme: Systemfehler 
oder andere katastrophale Ereignisse). 

act_close Der Container ist geschlossen, d.h. es kon- 
nen keine neue Operationen mehr beherbergt 
werden. Die Operationen bzw. deren Effek- 
te brauchen nicht unbedingt persistent gespei- 
chert zu sein. Ein erneutes Offnen, d.h. der 
Wechsel in einen kleineren Zustand mittels 
lock ist dann (und nur dann) zulassig, wenn 
nirgendwo kausale Abhangigkeiten von die- 
sem Container bestehen. 

act_freeze Wie act^close, jedoch ist ein Wechsel 
in kleinere Zustande nicht mehr moglich. 

|jf e Wie vorher, der Container samt beherbergtem 
Container-Inhalt ist jedoch mindestens 1 Mai 
persistent gespeichert und daher auch nach ein- 
fachen Systemfehlern wie Stromausfall noch 
erreichbar. 




act_multisafe Der Container(-Inhalt) ist mehrfach 
redundant gegen schwerere Systemfehler gesi- 
chert. 

Fur die Zustande gelten folgende Regeln: Anlegen 
eines Containers ist nur mit den Aktualitatsgraden 
act_destroyable bis act_tmp moglich. Eine un- 
lock-Operation setzt den Zustand alier von ihrem 
Adressbereich uberstrichenen und im Mandats-Eigentum 
befindlichen Container auf einen wahlbaren anderen 
Aktualitatsgrad; Zustands-Anderungen geschehen durch 
unlock mit Ausnahme von act__invalid nur in 
aufsteigender Richtung der Aktualitatsgrade. Der Zu- 
stand act^invalid ist von act_destroyable 
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bis act_close aus erreichbar (also insbesondere ab 
act_freeze nicht mehr erreichbar); ein einmal erreichter 
act_invalid-Zustand kann nie mehr verlassen werden. 

Weiterhin sollte beachtet werden, dass Zustandswechsel 
in hohere Aktualitatsgrade nur dann sinnvoll sind, wenn alle 
kausal vorangehenden Container mindestens den gleichen 
Aktualitatsgrad erreicht haben. Falls ein kausal vorange- 
hender Container auf act_invalid gesetzt wird, mus- 
sen alle davon kausal abhangigen Container ebenfalls auf 
act_invalidgesetzt werden. Dies entspricht den kaska- 
dierenden Rollbacks in klassischen Transaktions-Modellen. 

Die unlock-Operation kann damit sowohl die klassi- 
sche Funktionalitat von Rollback-Operationen von Trans- 
aktionen als auch von Commit-Operationen ausfuhren. Ein 
Rollback entspricht dem Zustand act_invalid, beim 
Commit wird je nach geforderter Fehlertoleranz ein Aktua- 
litatsgrad ab act_f reeze angesteuert. 
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7.7 Schnittstellen 
Operatioen 

7.7.1 Suchintervalle 

Ein Nest lasst sich im multiversion-Modell als zwei- 
dimensionalen Raum auffassen, der eine ortliche und eine 
zeitliche Dimension hat. Prinzipiell kann man jederzeit auf 
alle Teile dieses Raumes zugreifen. Dazu gibt es Suchope- 
rationen, mit denen sich Lock-Container im Nest aufspuren 
lassen. Zur Spezifikation von Suchintervallen schlage ich 
folgende Konventionen vor: 

Ein Suchintervall ist ein Paar ( start , delta ) , wobei 
start den Beginn und start + delta das Ende des 
Such-Bereiches angeben. Ein Suchintervall kann sich ent- 
weder auf die zeitliche oder auf die artliche Dimension be- 
ziehen. Bei positivem delta wird in aufsteigender Rich- 
tung gesucht, d.h. falls sich mehrere Lock-Container mit 
dem Suchintervall in der jeweiligen Dimension schneiden, 
wird nach dem Durchfiihren von Vergleichsoperationen und 
eventuell davon ausgeloster Verkleinerung (nur bei der zeit- 
lichen Dimension) diejenige Lock-Instanz ausgeliefert, die 
den kleinsten Wert in der jeweiligen Dimension hat und sich 
mit dem Suchintervall uberschneidet. Bei negativem del- 
ta wird in umgekehrter Richtung gesucht. 

Bie gleichzeitiger Suche nach Suchintervallen 
adr_search und timers ear ch werden diejenigen 
Lock-Instanzen ausgeliefert, die sich in beiden Dimensio- 
nen mit den jeweiligen Suchintervallen uberschneiden. Auf 
diese Weise ist eine Suche in einem rechteckigen Bereich 
des Ort-Zeit-Raumes moglich. 

Als Sonderfall kann weiterhin del ta= -}-oo oder del- 
ta= -co zur unbeschrankten Suche zugelassen werden, 
ebenso start= -Hx>. 



7.7.2 Lock-Operationen 
Modell 



im Multiversion- 



Die lock-Operation aus Abschnitt 3.3.5 wird im hier 
vorgestellten Erweiterungs-Vorschlag auf multiver- 
sion-Modelle aus methodischen Grunden in die bei- 
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den Operations- Varianten realPIock und wri te_lock 
aufgesplittet, da sie eine leicht unterschiedliche Parameter- 
Versorgung benotigen. Es sind jedoch auch geringfiigig an- 
dere Gestaltungen der Schnittstelle m6glich, die die Unifor- 
mitat der Schnittstelle beider Lock-Arten beibehalten. 
read_lock(nest , mandate , 

speculative_set , adr_set , time_set , 
act,min_act, stable, direct, aim, action) -> 
(adr_result, time_result) 
Die Parameter speculative_set und adr_set 
ubernehmen die Funktion von log_address, len, 
try_address und try_len aus Abschnitt' 3.3.5! 
Zusatzlich wird ein Vorschlag fur das Zeitstempel-Intervall 
time.set ubergeben. In den Ergebnis-Intervallen 
adr_result und time_result werden die tatsach- 
iich moglichen Orts- und Zeit-Intervalle zuruckgeliefert 
(sofern das Setzen des Locks iiberhaupt moglich ist). Das 
Orts-Invervall muss auf jeden Fall mindestens adr_set 
umfassen, das Zeit-Intervall kann gegeniiber time_set 
auch verkleinertausfallen. 

Der Parameter act gibt den Aktualitatsgrad des zu er- 
zeugenden Read-Locks vor. min_act gibt dagegen einen 
Aktualitatsgrad vor, den samtliche direkt kausal vorange- 
henden Write-Locks mindestens erfullen miissen. Falls sich 
in der direkten kausalen Abhangigkeit Write-Locks mit zu 
geringem Aktualitatsgrad befinden, muss im Regelfall so 
lange gewartet werden, bis diese den geforderten Aktuali- 
tatsgrad erreicht haben. Wenn man kleine Aktualitatsgrade 
fur min_act vorgibt, wird zwar die mogliche Parallelitat 
gesteigert (vgl. „dirty read" in Datenbanken), gleichzeitig 
steigt jedoch das Risiko kaskadierender Rollbacks und auch 
das Risko von inkonsistentem Lesen durch neu hinzukom- 
mende Beherbergungen in kausal vorgehenden Containern. 
Bei strengen Anforderungen an einzuhaltende Konsistenz- 
Bedingungen kann damit u.U. die Notwendigkeit von Roll- 
backs impliziert werden (vgl. Fehlersicherheit von Schedu- 
les [VGH93]). 

Die kausalen Abhangigkeiten werden im allgemeinsten 
multiversion-Modell persistent aufbewahrt, urn die 
Speicher-Semantik ^uch bei spater nachgelieferten „vor- 
datierten" Locks erfullen zu konnen. Der boolsche Para- 
meter stable gibt vor, ob die kausalen Abhangigkeiten 
„stabir sein sollen, oder ob sich spatere Locks „dazwi- 
schen schieben" diirfen. Bei stable = true diirfen spa- 
ter im Zeit-Intervall zwischen dem neu gesetzten Lock und 
dem kausal abhangigen Vorganger keine solchen Write- 
Locks mehr nachtraglich eingebaut werden, die zu irgend- 
einer Veranderung des Suchergebnisses bei der (erneuten) 
Bestimmung der funktionalen Abhangigkeiten aller mog- 
licherweise betroffenen Lock-Instanzen fuhren konnen 10 . 
Dadurch bestimmt der Eigentiimer eines Locks (d.h. das 
Mandat oder eine Menge von Mandaten), ob andere Locks 
mit ihm vertraglich sind oder nicht Wenn man diese Eigen- 
schaft auch transitiv fiir alle Vorganger der kausalen Ab- 

l0 Die Bestimmung aller mdglichweise betroffenen Lock-Instanzen 
muss nicht bei jedem Setz-Versuch neu erfolgen, wenn das Prinzip des' 
dynamic programming angewandt wird. Weiterhin darf eine fmplentierung 
das spatere Zwischenschieben von Locks auch dann zurUckweisen, wenn 
dies Iaut stable-Angaben m6glich ware. Dadurch lassen sich Heuristi- 
ken einfuhren, die z.B. relativ grosse Bereiche der Raum-Zeit-Ebene gegen 
das Setzen neuer Write-Locks sperren. 
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hangigkeiten ermoglicht (z.B. durch einen Aufzahlunostyp 
mit stable = transitive; die Bestimmung gilt unab- 
hangig vom urspriinglichen stable-Zustand der transitiv 
vorangehenden kausalen Abhangigkeiten), dann lassen sich 
verschiedene Transaktions- oder Konsistenz-Modelle belie- 
big miteinander mischen, ohne die jeweils intendierte Se- 
mantik zu verletzen (dies steht im Gegensatz zur herrschen- 
den Meinung iiber die Mischbarkeit verschiedener Model- 
le). 

Der boolsche Parameter direct bestimmt, ob die er- 
stellte kausale Abhangigkeit unbedingt vom ersten tatsach- 
hch vorhandenen Write-Lock in Suchrichtung abhangen 
muss, oder ob (z.B. in verteilten Systemen) veraltete Versio- 
nen geduldet werden. Letztere Moglichkeit verbessert die 
Performanz zu Lasten weniger strikter Konsistenz-Modelle 
und kann zu „uberspringenden" kausalen Abhangigkeiten 
ahnlich der PRAM-Konsistenz* 1 fuhren. 

Der Parameter aim dient als Ersatz Tur den friiheren Pa- 
rameter kind aus Abschnitt 3.3.5. Er gibt einen der Werte 
aim_address, aim_data oder aim_both an. Damit 
wird spezifiziert, ob nur die Adress-Abbildungs-Funktion 
des Nestes, oder die Daten-Abbildungs-Funktion, oder bei- 
de gegenUber konkurrierenden Zugriffen gesperrt werden 
sollen (weiterhin kann damit auch die Zulassigkeit der be- 
herbergten Operations- Arten gepruft werden). Adressmodi- 
fizierende Operationen wie move lassen sich dadurch von 
datenmodifizierendenOperationen wie transfer entkop- 
peln. Urn diese Fahigkeit besser auszunutzen, kann man 
beispielsweise einen weitere Parameter adr_t ime einfiih- 
ren, der den zu verwendenden Zeitstempel fur die Adres- 
sabbildung unabhangig von der Datenabbildung vorgibt. 
Damit konnen insbesondere solche Mandate einen un<*e- 
storten Zugriff auf die Nest-Adressen durchfiihren, die 
selbst keine adressmodifizierenden Operationen ausfuhren; 
diesen Mandaten erscheint dann die Adress-Abbildung als 
„festgenagelt", obwohl sie von andefen Mandaten auf der 
virtuellen Zeitachse geandert worden sein kann. 

Fur die Ortsangabe adr_set gilt ahnlich zu Ab- 
schnitt 3.3.5 die Regel, dass fur das gleiche Mandat fru- 
her gesetzte Locks (egal wo sich diese auf der Zeit- 
Achse befinden) „verdeckt" werden konnen. Jedes Man- 
dat hat zu jedem Zeitpunkt hochstens eine (eindeutige) 
Lock-Instanz-Zuordnung fur jeden (Teil-)Orts-Bereich; die- 
se eindeutige Zuordnung dient weiterhin der korrekten 
Versions-Zuordnungnachfolgenderget- und trans-fer- 
Operationen. Die Eindeutigkeit wird dadurch erzielt, dass 
bei nochmals angeforderten Adressbereichen die alten Ver- 
sionen bei Bedarf (d.h. nur bei geandertem Zeit-Bereich) 
ganz oder teilweise aufgegeben werden, d.h. aus der Ei- 
gentiimer Zuordnung entfernt werden (wodurch sie quasi 
„AlIgemeingut" werden). Aufgegebene Versionen, die nicht 
abgeschlossen sind, werden standardmaBig so behandelt, 
als wurden sie atomar durch unlock mit Aktualitatsgrad 
act_invalid (bei nicht-transaktionalen Untermodellen 
evtl. auch mit act_f reeze) freigegel?en und sofort wie- 



roco^ tere Konsistenzm °deIIe, insbesondere kausal haJbgeordnete (z.B 
[BSS91]), lassen sich ggf. im direct-Parameter durch Ersatz de< Typs 
boolean durch einen Aufzahlungtyp spezifizieren, der Zwischensiufen 
zwischen Ordnungslosigkeit und Totalordnung kausaler Abhangigkeiten 
ausdrUcken soil. 
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der an der neuen Zeit-Stelle neu gesetztrJTuf diese Weise 
ist sicher gestellt, dass Adressangaben bei get oder ande- 
ren Operationen stets eine eindeutig bestimmte Version ei- 
nes Locks bezeichnen unddas „Vererben" des Zeitstempels 
vom Container auf die beherbergten Operations-Instanzen 
eindeutig ist. 

write_lock (nest, mandate, 

speculative_set, adr_set , time_set , 
act, causal, aim, action) -> 
(adr_result, time_result) 
Gegeniiber read_lock kommt hier die direkte Angabe 
einer Menge (bzw. Liste oder Array) von Quadrupeln cau- 
sal hinzu. Ein Quadrupel hat die Form (adr_search, 
min_act, stable, direct). Der Wert von 
adr_search spezifiert den Ort, an dem die kausal 
vorgehenden Read- oder Write-Locks liegen. Durch die 
Aufnahme von min_act, stable und direct in die 
Quadrupel lassen sich diese Eigenschaften fur die funk- 
tionalen Abhangigkeiten in jedem Adressbereich einzeln 
einstellen 12 . 

Fa^im Suchbereich bereits ein Lock-Container mit Ak- 
t »^»^ d act - close e ^istiert, dessen bereits vorhan- 
d » JKsalen Abhangigkeiten eine kompatible Obermen- 
ge^WSn geforderten darstellen und der selbst nicht an spa- 
teren kausalen Abhangigkeiten teil nimmt, dann darf dieser 
Container an Stelle einer Neuerzeugung eines Containers 
erneut geoffnet werden. Diese Optimierung braucht nicht in 
jeder Irnplementierung unterstutzt zu werden; act_close 
darf beim unlock auch als act_f reeze behandelt wer- 
den.* 

unl ock (nest, mandate , adr_search , ac t ) 
Gegeniiber der fruheren Version aus Abschnitt £.3.5 kommt 
hier lediglich der Aktualitatsgrad act hinzu,'auf den die 
treizugebenden Locks gesetzt werden sollen. Es ist mog- 
lich. Locks mehrmals schrittweise auf immer hohere Ak- 
tualitatsgrade zu setzen, so dass eine korrekte Klammerung 
von lock / unlock-Paaren nicht mehr eingehalten wer- 
den muss. 
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Simulation einiger Transaktions- 
Strategien 



Verschiedene Varianten klassischer ACID-Transaktionen 
werden durch die soeben vorgestellten Lock-Operationen 
auf folgende Weise simuliert: 

Jeder einzelnen Schreib- und Lese- Operation, die sich 
auf einen noch nicht gelockten Adressbereich bezieht, wer- 
den Locks vorangestellt Read-Locks werden bei Bedarf 
dadurch in Write-Locks aufgewertet, dass auf dem glei- 
chen Adressbereich die andere Lock-Art, jedoch mit dem 
gleichen Zeit-Intervall angefordert wird. Ansonsten wer- 
den einmal angeforderte Locks bis zum Transaktions-Ende 
nicht mehr frei gegeben (2-Phasen-Locking). 

Die kausalen Abhangigkeiten werden nach der Grun- 
didee der Herbrand-Semantik syntaktischer Transaktions- 
Modelle [VGH93] stets so gesetzt, dass samtliche von ei- 
ner Transaktion jemals angefassten Adressbereiche bei den 
Write-Locks angegeben werden mussen. 

Beim Commit werden alle gesetzen Locks atomar 
durch unlock auf dem gesamten Adressraum (d.h. man 
wahlt adr_search = (0,oo)) mit mindestens act 
- act_safe abgeschlossen (sofern die D-Eigenschaft 
von ACID ausdriicklich bei jedem einzelnen Commit 
gefordert wird); beim Rollback ist stattdessen act = 
act_invalid zu wahlen. 

Bei den folgenden Simulationen konventioneller Trans- 
aktionen wird stets stable = true und direct = true 
gewahlt. Die einzelnen Transaktions- Varianten unterschei- 
den sich dadurch, welche Zeit-Intervalle und min_act- 
Werte jeweils beim Setzen der Locks gewaihit werden. 

7.8.1 Timestamp-Ordering-Protokolle 

Bei der Simulation von Multiversion-Timestamp-Ordering 
(MVTO) aus der Datenbank-Literatur [VGH93] wird die 
Serialisierbarkeit dadurch sicher gestellt, dass alle Ope- 



*«■ »«uui W i ai^uci gcsieiu, aass alle Upe- 

notity_lock(nest,mandate,adr_tr y/ adr_needrationen einer Transaktion als mit dem gleichen Zeit- 



time_need, aim, urgency) success 
IW^Bjeine (asynchrone) Ruckgabe eines nicht- 
a^J^ossenen Locks. Neben der Ruckgabe spekulativ 
vergrofierter Adressbereiche lasst sich Uber time__need 
auch die Verkleinerung von Zeit-Intervallen in verteilten 
Systemen konsistent durchftihren, wenn die Konvention 
herrscht, dass nicht abgeschlossene Locks nur von ihrem 
Eigentiimer verkleinert werden durfen. 



-Falls diese indivuelle EiastellmOglichkeit nicht bendtigt wird, kann 
man sie auch in die Parameter von lock verschieben und dadurch die 
Schnittstelle vereinfachen. Welche Semantik sich durch individuelle Ein- 
stellungen ergeben soli und ob diese im Sinne eines bestimmten seman- 
tischen Modells Oberhaupt giiltig ist oder zuriickgewiesen werden muss 
kann auch (teilweise) in der konkreten Baustein-Implementierung der 
Bearbeiter-Instanz festgelegt werden. Ansonsten hat der Aufrufer die Aus- 
wahl aus einer ungeheueren Vielzahl von Semantiken, die er durch sei- 
ne Parameter-Wahl vorgeben kann. Als sehr einfaches Beispiel lasst sich 
durch eine leere Menge von Qudrupeln spezifizieren. dass kerne funk- 
tionalen Abhangigkeiten bestehen; dies kann bei der Initialisierung oder 
beim Lfischen / unbedingten Oberschreiben des Dateninhaltes durchaus 
vorkommen und zusammen mit der RUckdatierungs-Moglichkeit auf der 
virtuellen Zeitachse die Parallelitiit dieses evtl. langdauernden Vorcanes 
mit anderen Akdvitaten steigern. 



stempel durchgefiihrt gelten; dadurch entsteht eine vir- 
tuell zeitliche Totalordnung aller Operationen, die ge- 
nau der Serial isierungs-Reihenfblge entspricht. Datenban- 
ken benotigen hierzu ebenfalls die Fahigkeit zur Verwai- 
tung mehrerer Versionen von Objekten (manchmal auch 
Time-Domain-Addressing genannt [GR93]). Der Zeitstem- 
pel wird bei Beginn der Transaktion oder beim ersten Zu- 
griff einmal so bestimmt, dass jede Transaktion einen ein- 
deutigen Zeitstempel besitzt, der nie mehr geandert wird. 

Die Simulation von Schreib-Lese-Transaktionen durch 
multiversion-Nester ist relativ einfach: die Locks 
werden mit time_set = (start, 0) und act = 
act_tmp gesetzt, wobei start den einmal bei Beginn 
der Transaktion eindeutig vergebenen Zeitstempel bedeutet. 

Nur-Lese-Transaktionen lassen sich dadurch simulie- 
ren, dass bei Beginn der Transaktion abweichend von 
der oben beschriebenen allgemeinen Strategic ein einziger 
Read-Lock auf dem gesamten Adressbereich adr_set = 
(0,oo) gesetzt wird, so dass die anschliessenden Lese- 
Operationen nicht mehr einzeln durch Read-Locks abge- 
sichert werden mussen. Ein derartiger Read-Lock, der den 
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gesamten Adressbereich umfasst, erzeugt einen Schnapp- 
schuss n des gesamten Nestes. 

Da auch bei Schreib-Lese-Transaktionen samtliche 
Read-Locks mit dem gleichen Zeitstempel gesetzt werden, 
Iassen sich auch hier die individuellen Read-Locks durch 
einen Schnappschuss-Lock ersetzen; beim Schreiben wer- 
den dann einzelne Teile des Schnappschuss-Locks durchld- 
chert und zu Write-Locks aufgewertet. 

7.8.2 Striktes 2-Phasen-Locking 

Bei der Simulation klassischer 2-Phasen-Locks [VGH93] 
wird das multiversion-Verhalten gar nicht ausgenutzt. 
Read- und Write-Locks werden auf dem Zeitintervall ti- 
me_set = (now.cxD) gesetzt, wobei now der streng 
monoton fortschreitenden aktuellen realen Uhrzeit beim 
Aufruf entspricht. Bei Gewahren des Locks wird dieses 
Zeitintervall auf den Gewahrungs-Zeitpunkt verkleinert, so 
dass nachfolgende Write-Locks auf der Zeitachse Platz 
finden. In den Quadrupeln der Write-Locks wird durch 
min_act = act_f reeze sicher gestellt, dass zu je- 
dem Zeitpunkt hochstens ein einziger nicht abgeschlossener 
Write-Lock auf iiberlappenden Adressen existiert. 

7.8.3 Weitere Arten von Serialisierbarkeit 
bzw. Konsistenzmodellen 

Es sind auch mehrere Write-Locks zum gleichen Real- 
Zeitpunkt moglich, die sich lediglich nicht auf der vir- 
tuellen Zeitachse uberschneiden durfen. Man konnte dies 
mit Multiversions-Locking bezeichnen. Die Moglichkeit, 
uberlappende Adressbereiche zum gjeichen Real-Zeitpunkt 
sperren zu konnen, geht jedoch uber'den Begriff „multi ver- 
sion concurrency control 14 " [HR01] bzw. den Begriff der 
Multiversions-Konflikt-Serialisierbarkeit [VGH93] hinaus. 
Eventuell ware Time-Domain-Locking eine gute Bezeich- 
nung zumindest fur die englischsprachige Literatur. 

Der verallgemeinerte Serial isierungs-Begriff aus 
[Vid87], der sowohl die Konflikt- als auch die MVTO- 
Serialisierbarkeit als Spezialfall enthalt, durfte sich durch 
die hier vorgestellte Nest-Schnittstelle ebenfalls simulieren 
Iassen. Dies gilt ebenso fur Protokoll-Familien wie MVS- 
GT (Multiversions-Serialisationsgraphen-Tester), die sich 
als konkrete Strategien in Bausteinen realisieren Iassen. 

Geschachtelte Transaktionen Iassen sich durch Bausteine 
realisieren, die Gruppen von Anderungs-Operationen nach 
aussen hin durch gesammelte Lock-Operationen weiterge- 
ben und dabei ggf. die Aktualitatsgrade in andere Werte 
transform ieren. 

Durch „uberspringende" kausale Abhangigkeiten, 
Aufweichen der Herbrand-Semantik und Variation der 
min_act- » stable- und direct-Parameter Iassen 
sich weitere Serialisierbarkeits-Begriffe bilden, deren 
systematische Untersuchung weiteren Arbeiten uberlassen 

,3 Im Unterschied zu [CL85] litest sich ein Schnappschuss auch rdckwir- 
kend in der virtuellen Zeitachse machen. 

,4 Bisher wurde Versionierung in Datenbanken offenbar nur zur Entkop- 
pelung zwischen Lesern und Schreibern eingesetzt. Das hier vorgestellte 
Modell ermQglicht dagegen prinzipiell auch die Entkoppelung zwischen 
parallel aktiven Schreibern; Einschrankungen ergeben sich lediglich aus 
den kausalen Abhangigkeiten. 



bleibt Ein grosses Forschungs-Feld stellen Optimierungen 
bei sich widersprechenden Zielen dar, beispielsweise 
wenn spekulativ vergroBerte Lock-Bereiche nur mit „uber- 
spnngenden" kausalen Abhangigkeiten oder geringerem 
Aktualitatsgrad erkauft werden konnen 15 u. v.m. 

Durch gezieltes Freigeben einiger Locks vor 
Transaktions-Ende Iassen sich beliebigeMisch-Paradigmen 
zwischen vollkommener transaktionaler Isolation und 
wechselseitigem Ausschluss realisieren 16 . Der bisher in 
Betriebssystemen verwendete wechselseitige Ausschluss 
wird durch das Konzept der Aktualitatsgrade so orthogonal 
erganzt, dass ein nachtragliches Rucksetzen schiefgegange- 
ner Berechnungen (die mit Berechnungen anderer Mandate 
nicht-serialisierbar verwoben sein konnen) moglich ist. 

7,8.4 Automatische Re-Evaluation 

Die Idee besteht darin, in den Containern (gelegentlich oder 
teilweise auch in den gespeicherten kausalen Abhangigkei- 
ten) nicht (nur) die Ergebnisse der von den Konsumenten 
generierten Zugriffs-Operationen zu beherbergen, sondern 
(zusatzlich) ihre Berechnungsvorschrifi. 

Dadurch kann man die beherbergten Zugriffs- 
Operationen neu berechnen, wenn nachtragliche An- 
derungen bei einem der kausal vorgehenden Container oder 
nachtragliches Einschieben von Write-Locks in stabile 
kausale Abhangigkeits-Beziehungen zugelassen werden, 
wodurch die kausalen Abhangigkeiten auf die neuen Ver- 
sionen abgeandert werden. Bei solchen Anderungen wird 
lediglich eine Neuberechnung des Container-//i/w/te.y aller 
transitiv kausal abhangigen Container angestossen; die 
Container selbst und ihre Position in der Raum-Zeit-Ebene 
bleiben erhalten. 

Eine Spezirikation der Berechnungsvorschrift kann 
durch Einfuhren eines geeigneten Interpreters und einer 
Interpreter-Sprache erfolgen, von der Programmstiicke mit- 
tels einer Operation download bekannt gemacht werden 
(z.B. zur Addition von Zahlen-Werten oder Berechnung ei- 
ner Summe). Das Herunterladen von ausfuhrbarem Maschi- 
nencode ist prinzipiell ebenfalls moglich, hat jedoch Nach- 
teile bei der Sicherheit (zu deren Losung kann man spezi- 
elle Konventionen fur die wahrend der Evaluation aktiven 
Schutzbereiche einfuhren). 

In beiden Fallen sollten moglichst alle Konsumen- 
ten ihre trans fer-Operationen zum Andern der Daten- 
und/oder Adressabbildung von Nestern durch download- 
Operationen ersetzen, damit nicht-reevaluierbare Container 
dieses Verfahren nicht stoppen konnen oder inkorrekt wer- 
den Iassen. 



Die klassischen Flaschenhals-Probleme verteilter Systeme. insbeson- 
dere die durch Latenzen verursachten, Iassen sich ebenfalls unter dem 
Aspekt sich widersprechener Optimierungs-Ziele (Tradeoffs) betrachten. 
Interessant ware eine Vereinheitlichung der Darstellung dieses Gebiets mit 
den hier aufgeworfenen Tradeoffs. 

l6 Eine griffige Formel zur Charakterisierung beider Extreme konnte auf 
dem Hintergrund der Betrachtung von Locks als Container auf der virtuel- 
len Zeitache folgendermassen lauten: Bei transaktionaler Semantik werden 
Container so lange wie mdglich offen gehalten (urn sie ggf. fdr invalide 
erkliiren zu kSnnen), beim wechselseitigen Ausschluss werden Container 
dagegen so frUh wie mbglich geschlossen. 



Anhang A 

Simulation von Vererbung durch Generizitat 



Zum Nachweis, dass sich Erweiterungs-Generizitat mit Hilfe von Parametrischer Generizitat ausdrucken lafit, simulieren 
wir die Kernidee der objektorientierten Vererbung durch Praprozessor-Makros der Sprache C: 



f; 



// Allgemeine Deklarationen 
^define class struct 



ist iterators 

tine decl_method(base, type, name) base##_##nameft#_head( (*base##_##name) , class type), 
efine def_method (base, type, name) \ 
static base##_##name##_head(base##_##name, class type) \ 
base##_##name##_body (class type) 
#define init_item (base, type, name) self->type##_#&name = type##_##name; 

// Hilfs-Makros 

#define init_head(type) void type##_init (class type * self) 

#def ine declarations ( type) type##_attribs type##_list (decl_method, type, type) 
fldefine inherit (base, type) base##_attribs base#ft_list (decl-method, base, type) 
#define inherit_init (base, type) base##_init < (class base*)self); 

// Haupt-Makros 4 
#define base_class ( type) \ 
class type; \ 

\ 

type#*L_list (def_method, type, type) \ 

\ 

class type { \ 
declarations ( type) \ 
>; \ 

\ 

t_head(type) \ 

\ 

ype##_list(init_item, type, type) \ 



#define sub_cl ass (base, type) \ 
class type; \ 

\ 

type##_JList(def_met hod, type, type) \ 

\ 

class type { \ 

inner i t ( base , type ) \ 

declarations (type) \ 
) I \ 

\ 

i ni t_head ( type ) \ 
{ \ 

inher i t_ini t < base , type ) \ 

type##_list(init_item, base, type) \ 

> 

Auf diese allgemeinen Deklarationen hin folgt nun die einmalige Angabe zweier Klassen A und B mittels Makro- 
Definitionen: 
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// spezifisch fuer A 

#define A_attribs \ 
int raemberl; \ 
int member 2 ,- 

fcdefine, A_methodl_head{ name, type) \ 
void name {type * self) 

#define A_jnethodl_body ( type) \ 

{ \ 

/*...*/ \ 

} 

#def ine A_method2_head ( name , type ) \ 
void name (type * self) 

#define A_jnethod2_body ( type) \ 
( \ 
/*...*/ \ 

} 

#define A_list (op,b« t) op ( b , t , methodl ) op <b, t , method2 ) 

// Anwendung A 

base_class (A) 

// spezifisch fuer B 

#define B_attribs \ 
int member 3 ; . \ 
int member4; 

#define B_method3_head (name, type) \ 
void name (type * self) 

#define B_method3__body ( type) \ 
{ \ 
/*...*/ \ 

> 

#define B_list (op, b, t) op (b, t , method3 ) 

// Anwendung B 
sub__class (A,B) 



Mit Hilfe der Unix-Kommandos gcc -E vererbung.c | grep -v "*#' | indent -bad -bap | in- 
dent -kr entsteht hieraus der folgende expandierte Quelltext: 



struct A; 

static void A_methodl (struct A *self) 

{ 

} 

static void A_jnethod2 (struct A *self) 

{ 

} 

struct A { 

int member 1; 
int member2; 

void (*A_methodl) (struct A * self); 
void (*A_method2) (struct A * self ) ; 

}; 

void A_init (struct A *self) 
( 

self->A_jnethodl « A_methodl; 
self->A__method2 = A_jnethod2; 

} 

struct B; 

static void B_method3 (struct B *self) 

{ 

} 

struct B { 
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); 



int member 1; 
int member2; 
void ( *A_methodl ) 
void ( *A_jnethod2 ) 
int member3; 
int member 4; 
void (*B_method3) 



♦ 



ANHANGA. SIMULATION VON VERERBUNG DURCH GENERIZTTAT 



(struct 
(struct 



self) 
self) 



(struct B * self) ; 



void B_init (struct B *self) 
( 

A_init( (struct A *) self ) ; 
self->B_method3 = B_method3; 




* 



Anhang B 



Beispiel-Probleme der Objektorientierung 




Ein Beispiel, bei dem die Mitvererbung von Datenstruk- 
turen bzw. Reprasentationen zu einer kombinatorischen Ex- 
plosion von Klassen fuhren kann: 

Die Erweiterung einer abstrakten Basisklasse G solle auf 
zwei verschiedene voneinander unabhangige Arten stattfin- 
den. Dies laBt sich relativ einfach durch zwei verschiede- 
ne abgeleitete abstrakte Basisklassen A und B durchfuh- 
ren. Aus jeder der beiden abstrakten Basisklassen seien ver- 
schiedene konkrete Klassen A u . . . , A n und B u . . . B m 
abgeleitet, deren Funktionalitat jeweils benotigt werde. Nun 
komme die Anforderung hinzu, dass die Vereinigung beider 
Schnittstellen ebenfalls benotigt werde. Auf der Ebene der 
abstrakten Basisklassen ist dies sehr einfach durch eine wei- 
tere Basisklasse C zu bewerkstelligen, die ihre Schnittstelle 
aus A und B durch Mehrfachvererbung erhalt Dies bedeu- 
tet fur die davon abgeleiteten konkreten Klassen dj jedoch, 
dass nun das gesamte kartesische Produkt aus n • m abge- 
leiteten Klassen in Frage kommt und ggf. zu implementie- 
ren ist. Selbst wenn dabei keine neue Funktionalitat mittels 
uberschriebener Methoden-Implementierungen hinzukom- 
men sollte, fuhrt dies zu einer kombinatorischen Explosion 
der Klassen-Namen und zu einer Aufblahung des gesamten 
Systems. Nach meinem Dafurhalten taucht dieses Problem 
oft in der Praxis auf, ohne erkannt zu werden. 

Fur dieses Problem gibt es eine oft funktionierende Lo- 
sung, ohne das objektorientierte Paradigma verlassen zu 
mtissen. Die Implementierung einer abgeleiteten Klasse 
Cij sollte nicht durch Mehrfachvererbung erfolgen, sondern 
durch Container-Instanzen aj e C ijt die jeweils zwei In- 
stanzen a { <E A { und bj € Bj enthalten (in Form einer 
has-a-Beziehung statt einer is-a-Beziehung). Man kann dj 
auch als Proxy-Klasse bezeichnen. Dies bringt jedoch fol- 
gende Schwierigkeiten mit sich: 

L Die bisherigen Attribute waren Mitglieder der alten 
Objektinstanz-Reprasentation; von der neuen Repre- 
sentation werden sie entweder indirekt adressiert oder 
sie werden nochmals eingebettet. Dadurch wird Platz 
verschwendet. 

2. Die gemeinsame Oberklasse G kann Attribute enthal- 
ten, die bei der Mehrfachvererbung nur einmal ge- 
meinsam instantiiert werden sollen. 



Der Namensraum wird nach wie vor durch n 
schiedene Klassennamen verschmutzt. 



m ver- 



Das erste Problem ist lastig, gefahrdet aber die Korrektheit 
nicht. Zur Losung des zweiten Problems kann man eine drit- 



te Komponente g e G in die Container-Ins tanz einfiihren. 
Das dritte Problem ist nicht zu umgehen und belastet im 
giinstigsten Fall nur den Compiler. 

Es gibt jedoch noch eine weitere Losung: man fuhrt ei- 
ne Klasse C ein, die die Summe der Schnittstellen enthalt 
und ansonsten nur als trivialer Container fungiert, der die ei- 
gentliche Implementierung in G t A und B aufruft (was den 
Schnittstellen-Aufwand etwa verdoppelt). Damit betreibt 
man in der Objektorientierung jedoch letztlich die gleiche 
Art von Einbettung von Unterobjekt-Instanzen, wie sie in 
„konventionellen" Programmierparadigmen schon immer 
gehandhabt wurde; es wird lediglich ein Zusatz-Aufwand 
mit Duplizierung von Schnittstellen getrieben, urn das ob- 
jektorientierte Paradigma mittels Mehrfachvererbung an der 
Schnittstelle retten zu konnen. Es stellt sich die Frage, 
ob die konzeptuell durch Mehrfachvererbung entstandene 
Schnittstelle C, deren Implementierung allerdings keine 
(Mehrfach-)Vererbungbenutzt, wirklich benotigt wird, oder 
ob die durchgehendeBenutzung von A und B als Ersatz fur 
C nicht unter dem Strich einfacher ist, Unabhangig davon 
sehe ich das fur die Objektorientierung wesentliche Para- 
digma der Vererbung nicht mehr als tatsachlich benutzt, und 
ich stelle die Frage, ob man es nicht gleich von vornherein 
hatte weglassen konnen. 

Dies bedeutet nach meiner Ansicht nicht, dass die auto- 
matisierte Ableitung von objektorientierten Datenschema- 
ta aus Klassen-Schemata generell nutzlos ist, denn es gibt 
sehr wohl An wendungsf elder, wo die automatische Ablei- 
tung immer wiederkehrende Arbeitsvorgange rationalisiert. 

Ich bin der Ansicht, dass die Objektorientierung ein oft 
nutzliches Denkschema zum Entwurf von Schnittstellen ist; 
dass aber eine unreflektierte Umsetzung dieses Schemas 
in konkrete Datenstrukturen kostspielig oder sogar gefahr- 
lich werden kann, da die ublicherweise angebotenen Daten- 
Reprasentationen nicht fur die Aufgabenstellung optimal zu 
sein brauchen. 

Auf methodischer Ebene scheint mir das geschilder- 
te Problem auch darin zu liegen, dass objektorientierte 
Entwurfs-Denkweise oftmals auf Biegen und Brechen ver- 
sucht, alles mittels Erweiterungs-Generizitat zu Idsen. Die 
hier vorgefuhrte Problemstellung passt jedoch zur kompo- 
sitorischen Generizitat viel besser. 

Dieses Beispiel ist daher ein weiteres Argument fUr den 
von mir propagierten Vorrang kompositorischer Generizitat 
vor Erweiterungs-Generizitat. 
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Anhang C 

Ansatze zur Vermeidung von Wettrennen 



1 . Man sorgt dafur, daB stets genugend Ressourcen vor- 
handen sind und ein Entzug daher niemals notwen- 
dig wird. Leider spricht die Realitat oft dagegen, da 
Ressourcen stets endlich sind und nach einem Quasi- 
Naturgesetz oft nicht zur Deckung des Bedarfs aus- 
reichen. Wenn der Bedarf limitiert ist oder wenn man 
bereits bei der Ausgabe von Ressourcen Limits ein- 

^^Mirt (z.B. Quota), kann man u.U. auf Ruckforde- 
M jksmechanismen verzichten. Ebenfalls in diese Ka- 
^ P nc fallt z.B. der Tausch von gleichwertigen Res- 
^^Durcen, bei dem ebenfalls eine Ruckforderung in Zu- 
kunft ausgeschlossen werden kann. Im Sinne des Ei- 
gentum / Besitz-Modells (Abschnitt 5.1) bedeutet dies, 
dass echtes Eigentum (nicht nur bloBer Besitz) ubertra- 
gen wird, das nie mehr zuruckgefordert werden kann. 

2. Man verlangt, daB Besitz grundsatzlich nur an hierar- 
chisch tieferstehende Instanzen und nur fur die Dauer 
der Bearbeitung einer Operation weitergegeben wer- 
den darf; damit wurde das Konzept des Iogischen IO 
nicht mehr benutzt und das Modell eingeschrankt. 

3. Man erlaubt nur die Ruckvergabe von solchem Unter- 
besitz an hohere Instanzen, der bereits einmal von der 
gleichen hoheren Instanz als Hauptbesitz an die nied- 
rigere vergeben wurde (transitive Riicklieferung von 

^JJnterobjekten). Damit gehort der Unterbesitz in Wirk- 
^^^jriceit stets der hoheren Instanz; eine Ruckforderung 
I P h den Hauptbesitzer wird als unberechtigt klas- 
^■Hziert und nicht ausgefuhrt bzw. gar nicht erst ver- 
sucht. Diese Konstruktion erweitert das Modell gegen- 
iiber 2. ohne gravierende Nachteile einzufuhren; daher 
gebe ich ihm den Vorzug gegeniiber 2. AUerdings se- 
he ich es immer noch als relativ stark eingeschrankt an, 
insbesondere fur Anwendungen in verteilten Systemen 
und Netzwerk-Betriebssystemen. Auf der konzeptuel- 
len Ebene scheint mir eine Vertauschung von Etiketten 
statt zu finden, da in Wirklichkeit keine echte Delega- 
tion von Macht iiber den Besitz statt finder.. 

4. Man vergibt Besitz an hohere Instanzen (ggf. auch an 
niedrigere Instanzen) grundsatzlich nur auf begrenz- 
te (Real-)Zeit, innerhalb deren die Ressource entwe- 
der zuruckgegeben oder die Verleihzeit verlangert wer- 
den muB; die Zeitschranke wird so bemessen, daB 
ein Verfall des Leihdatums im Normalbetrieb nicht 
stattfindet. Nach diesem Modell ist es die Pflicht ei- 
nes jedes Ausleihers, entweder fur rechtzeitige Riick- 



gabe oder fur Fristverlangerung zu sorgen (analog 
zum Ausleih-Verfahren einer Universitats-Bibliothek). 
Wenn die Zeitschranke iiberschritten wird, dann liegt 
in diesem Sinne ein Fehlverhalten vor, und die Res- 
sourcen konnen z.B. automatisch entzogen werden. 
Dieser Entzug hat jedoch wieder den Charakter eines 
asynchron auftretenden Signals, d.h. es andert nichts 
am Prinzip der Ruckgabe, nur am Ausloser. Dieses 
Modell eignet sich insbesondere fur einige Anwendun- 
gen in verteilten Systemen, da eine nicht rechtzeitig 
erfolgte Ruckgabe bzw. Verlangerung auch als Aus- 
fall einer Instanz interpretiert werden kann, auf den 
dann z.B. mit automatischen Entzug des Ressourcen- 
Besitzes und Neuverteilung reagiert wird; falls die In- 
stanz nicht tatachlich ausgefallen war, sondern nur die 
Kommunikationsverbindung, dann „weiB" die betrof- 
fene Instanz nach Ablauf der Frist, dass sie die Verlan- 
gerung nicht mehr rechtzeitig geschafft hat und dass 
sie daher nicht mehr „rechtmaBiger" Besitzer ist. 

5. Die Besitzvergabe an hohere Instanzen geschieht aus- 
schlieBIich unter der vollen Kontrolle der niedrigeren 
Instanz, die vollstandig bestimmen kann,' was damit 
geschieht. Damit wird jedoch das Hierarchie-Modell 
auch im regularen Betrieb auf den Kopf gestellt; es 
wurde sich die Frage stellen, ob es noch eine Berech- 
tigung hat. Auch die Eignung fur verteilte Systeme 
scheint mir hochst zweifelhaft. 

Keiner dieser Ansatze scheint mir geeignet, das Wettrenn- 
Problem (Kapitel 5) so aus der Welt zu schaffen, daB da- 
durch keine neuen Probleme entstehen und dass Anforde- 
rungen von verteilten Systemen ausreichend berUcksichtigt 
werden. Eine Bewertung, welche dieser Probleme als ge- 
wichtiger zu betrachten ist, kann je nach Standpunkt des 
Bewerters und nach Anforderungen an das System unter- 
schiedlich ausfallen (beispielsweise sehe ich bei extrem 
sicherheitskritischen Anwendungen Vorteile bei Modell 
3). Es ist grundsatzlich moglich, eine konkrete Baustein- 
Hierarchie innerhalb der hier vorgestellten Architektur so 
zu gestalten, daB notify_*-Operationen und deren Wett- 
rennen vermieden werden; dies sehe ich dort als erstrebens- 
wert an, wo eine Vermeidung ohne weiteres moglich ist 
und nur geringe Kosten verursacht. Ich sehe jedoch geringe 
Chancen, Wettrennen in einem verteilten System so zu ver- 
meiden, daB keine Performanz-Nachteile oder Abhangig- 
keiten von der Funktionsfahigkeit zentraler Instanzen ent- 
stehen. 
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AnsprQche 

1. Verfahren zur Regulierung des Datenzugrif f s bei einem 
aus mehreren Einzelsystemen bestehenden. System auf Daten we- 
nigstens einer Datenspeichereinrichtung, bei dem die Einzel- 
systeme sich f reie Daten- Oder Adressenbereiche der Daten- 
quelle reservieren und die reservierten Bereiche fxir einen 
Zugriff durch andete Einzelsysteme dann gesperrt sind, wobei 
die Reservierungen (Locks) eine ortliche und eine zeitliche 
Komponente besitzen. 

2. Verfahren zur Regulierung des Datenzugrif fs auf Daten 
wenigstens einer Datenspeichereinrichtung, bei dem Adressen- 
bereiche und/oder Teiladressenbereiche der Datenspeicherein- 
richtung dadurch verschoben werden r dass unter Beibehaltung 
der physischen Adressen die Zuordnung von logischen Adressen 
zu den physischen Adressen gemafi der Verschiebeoperation ge- 
andert wird. 

3 • Verfahren zur Regulierung des Datenzugrif fs bei einem 
aus mehreren Einzelsystemen bestehenden System auf wenigstens 
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eine Datenspeichereinrichtung, bei dem die Einzelsysteme sich 
freie Daten- oder Adressenbereiche der Datenspeichereinrich- 
tung* reservieren und die reservierten Bereiche fur einen 
Zugriff durch ahdere Einzelsysteme dann gesperrt sind, wobei 
gegenuber den direkt benotigten Bereichen spekulativ vergr6- 
Serte Bereiche reserviert werden. 

4. Verfahren nach Anspruch 3, dadurch gekennzeichnet , dass 
der jeweils uber den direkt benotigten Bereich hinausgehende 
reservierte Erweiterungsbereich bei einer entsprechenden Re- 
servierungsanf rage seitens eines anderen Einzelsystems oder 
einer Datenspeichereinrichtung wenigstens teilweise freigege- 
ben wird. 
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